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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The Digital Video Broadcasting Project (DVB) is an industry-led consortium of broadcasters, manufacturers, network 
operators, software developers, regulatory bodies, content owners and others committed to designing global standards 
for the delivery of digital television and data services. DVB fosters market driven solutions that meet the needs and 
economic circumstances of broadcast industry stakeholders and consumers. DVB standards cover all aspects of digital 
television from transmission through interfacing, conditional access and interactivity for digital video, audio and data. 
The consortium came together in 1993 to provide global standardisation, interoperability and future proof 
specifications. 

The present document is part 2 of a multi-part deliverable covering the Digital Video Broadcasting (DVB); IP Datacast: 
Program Specific Information (PSI)/Service Information (SI), as identified below: 

Part 1: "IP Datacast over DVB-H"; 

Part 2: "IP Datacast over DVB-SH". 



Introduction 

The contents of the present document specify the use of PSI and SI tables and related descriptors in DVB-SH networks, 
and more generally of all signalling elements relevant to the usage of DVB-SH network (TPS, Signalling Field, SHIP). 
TS 102 470-1 [8] is a corresponding document describing usage of PSI/SI information in IPDC in 
DVB-H systems. 

The present document describes how the network infrastructure is required to generate the signalling. In some cases, the 
behaviour of the receiver is also specified. More general description of receiver behaviour and not-directly PSI/SI 
related signal generation is FFS in DVB-SH the implementation guideline. 
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The use of PSI/SI tables and/or descriptors not mentioned within this clause is either not restricted for any particular 
network and specifying the use of such tables/descriptors is either outside of the scope of the present document, or can 
be applied for both DVB-H and DVB-SH networks and therefore can be found in [8]. 

Clause 4.1 provides some introduction to the PSI/SI in DVB-SH. 

Clause 4.2 specifies content regionalization concept within a "partially available TS". 

Clause 4.3 specifies MPE usage. 

Clause 4.4 specifies the descriptors required and their usage. 

Clause 4.5 specifies the PSI tables usage. 

Clause 4.6 specifies the SI tables usage. 

Clause 4.7 specifies the TPS and Signalling Field parameters and their usage. 

Clause 4.8 specifies the Update Notification Table usage. 

Clause 4.9 specifies the INT announcement usage. 

Clause 4.10 specifies SHIP usage. 

Clause 4.11 specifies the signalling field usage. 
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1 Scope 

The present document provides focus on PSI/SI tables and descriptors used in DVB-SH Systems. 

Used tables and descriptors are introduced, and their usage is described. 

The present document defines the set of PSI/SI data a DVB-SH Receiver may expect to be available on a DVB-SH 
bearer (data transmission baseband) and the DVB-SH Network is expected to make available on the DVB-SH Bearer. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were vaUd at the time of publication, ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI EN 300 468: "Digital Video Broadcasting (DVB); Specification for Service Information (SI) 

in DVB systems". 

[2] ETSI EN 301 192: "Digital Video Broadcasting (DVB); DVB specification for data broadcasting". 

[3] IETF RFC 1 1 12: "Host extensions for IP multicasting". 

[4] IETF RFC 2464: "Transmission of IPv6 Packets over Ethernet Networks". 

[5] Void. 

[6] ETSI EN 302 583: "Digital Video Broadcasting (DVB); Framing Structure, channel coding and 

modulation for Satellite Services to Handheld devices (SH) below 3 GHz". 

[7] ETSI TS 102 594: "Methods for Testing and Specification (MTS); Internet Protocol Testing (IPT): 

IPv6 Security; Conformance Abstract Test Suite (ATS) and partial Protocol Implementation eXtra 
Information for Testing (PIXIT) proforma". 

[8] ETSI TS 102 470-1: "Digital Video Broadcasting (DVB); IP Datacast: Program Specific 

Information (PSI)/Service Information (SI); Part 1: IP Datacast over DVB-H". 

[9] ETSI TS 102 584: "Digital Video Broadcasting (DVB); DVB-SH Implementation Guidelines". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] ETSI TR 101 211 (VI. 10.1): "Digital Video Broadcasting (DVB); Guidehnes on implementation 

and usage of Service Information (SI)". 
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3 Definitions and abbreviations 

3.1 Definitions 

3.1.0 Introduction 

For the purposes of the present document, the following terms and definitions apply (only those definitions which are 
specific to the present document and complementary to the definitions found in TS 102 470-1 [8] are listed here). In 
addition, definitions have been classified according to their nature and scoping in three categories: infrastructure, 
transport containers, tables and signalling structures. 

3.1.1 Infrastructure 

DVB-SH: transmission system targeted to provide IP-based services to handheld terminals over hybrid global and local 
radio channels, as defined in EN 302 583 [6] and EN 301 192 [2] 

DVB-SH bearer: link and physical layers into which IP packets are encapsulated according to DVB-SH specifications 

DVB-SH receiver: equipment or system can receive IP based services provided over a DVB-SH bearer 

DVB-SH region: group of cells transmitting same content on a partially available TS 

DVB-SH distribution network: network that transports a TS from a central head-end to a network of DVB-SH 
repeaters 

NOTE 1 : The distribution network includes: 

the gateways, both at central (transmission gateway) and remote (reception gateway) places; 

the network itself, usually a satellite and/or an IP network. 

NOTE 2: We distinguish between global and a local distribution network, depending on the coverage requirements: 

global distribution network enables to reach all repeaters (e.g. via a satellite coverage); 

whereas a local distribution network enable reach of only a subset of the repeaters. 

DVB-SH adaptation: function of customizing a "complete TS" to a region while preserving the PSI/SI identification 

NOTE 1 : TS_id is kept the same, only content is locally removed and this is signalled by using 
service_availability_descriptor. 

NOTE 2: More generally SI tables are kept unique and identical in all regions, PSI are specific to each region. 

NOTE 3: This adaptation function can be performed either on the head-end (central adaptation) or on the repeater 
(remote adaptation). The content removal can be done at SH or DVB service level. 

DVB-SH {adaptation; distribution}: function combining together DVB-SH adaptation and distribution 

NOTE 1: Different options are possible among which "adapt then distribute" and "distribute then adapt". Order can 
therefore vary between both elements so this common definition enables to describe all cases more 
generically. If needed the adapter/distribution element can be identified individually. 

NOTE 2: The combination of both functions is not specified and left to implementation. However interfaces to and 
from these combined functions are specified. 

DVB-SH adapter: equipment performing the DVB-SH adaptation function 

DVB-SH head-end: group of equipments in charge of generating a SH-compliant TS and interfacing it with a 
distribution network 

NOTE 1 : A DVB-SH head-end can have a SH adaptation function in case of central adaptation. 
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NOTE 2: We distinguish between a global and a local head-end depending on the type of distribution network to 
which the head-end is connected. 

DVB-SH modulator: function that takes at its input a SH-compliant TS with its SHIP signalling and modulates it 
according to DVB-SH waveform standard [6] 

NOTE: The modulator synchronizes itself using a SHIP MPEG2 packet. 

DVB-SH repeater: equipment in charge of modulating a TS according to DVB-SH physical waveform [6] 

NOTE: By nature, this equipment includes a DVB-SH modulator. In addition, it MAY include: 

a DVB-SH distribution reception gateway in case the repeater is not co-located with the 
DVB-SH head-end; 

a DVB-SH adapter in case of remote adaptation (see Figure 3). 

Low Latency: DVB-SH system using the optional low-latency extension as specified in Annex B of the DVB-SH 
waveform standard [6] 

NOTE: A system or equipment supporting the low latency extension is named DVB-SH-LL. 

Regular Latency: regular DVB-SH system according to the DVB-SH waveform standard [6] that is either not aware or 
not including the optional low-latency extension as specified in Annex B 

NOTE: Within the context of the present document "regular latency" is also referred to as "regular". 

Regular IP encapsulator, regular transmitter, regular receiver: equipment that is working according to the current 
standard 

NOTE: An encapsulator is not aware of the low latency extension (according to DVB-SH waveform 
standard [6]). 

DVB-SH network: DVB network that conveys DVB-SH bearers to DVB-SH receivers 

NOTE: The DVB-SH network is composed of the infrastructure and the receivers. A generic overview of the 
DVB-SH infrastructure is presented in Figure 1. Various options are also presented in Figure 2 and 
Figure 3. 
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Figure 1 : DVB-SH infrastructure synoptic 
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Figure 2: DVB-SH infrastructure in case of central adaptation 
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Figure 3: DVB-SH infrastructure in case of remote adaptation 

3.1.2 Transport containers 

SH service: fraction of the MPEG2 TS signalled to the modulator via the SHIP 

NOTE: A SH service is an entity that can be processed by a modulator. SH service can be used for filtering 
purpose and regionalization. 

Partially available DVB/SH service: DVB/SH service that is not present in all cells where the TS is modulated 

NOTE 1: DVB service presence is informed by the service_availability_descriptor in SDT whereas the SHIP 
informs SH service presence. 

NOTE 2: A partially available DVB/SH service carries local content. A synonym of a paDVB/SH service is a local 
DVB/SH service. 

Coimnon DVB/SH service: DVB/SH service that is present in all cells where the TS is modulated 

NOTE 1: DVB service presence is informed by the service_availability_descriptor in SDT whereas the SHIP 
informs SH service presence. 

NOTE 2: A common DVB/SH service carries common content. There can be zero, one or more of such common 
DVB/SH services in a given TS. 

Low Latency DVB/SH service: special, partially available DVB/SH service 

NOTE 1 : DVB service presence is informed by the service_availability_descriptor in SDT whereas the RL SHIP 
informs SH service presence and the LL SHIP informs about the position in the stream. 

NOTE 2: A low latency DVB/SH service carries low latency content. There can be zero, one or more of such low 
latency DVB/SH services in a given TS. 

NOTE 3: A low latency DVB/SH service is a partially available DVB/SH service that has different physical layer 
parameters (see [6], Annex B) and is processed differently in the modulator, but which is treated as a 
(normal) partially available DVB/SH service from the PSI/SI point of view. 

Partially available TS: TS that signals in the PSI/SI one or more partially available DVB/SH service(s) 

NOTE: This definition has nothing in common with the partial TS referred by the partial TS descriptor in [1]. 

Complete TS: partially available TS where all signalled services, including the paDVB/SH ones, are actually present 

NOTE: Complete TS has to be considered for generating the PSI/SI information coherently (in particular the SI 

that is required to be unique). However complete TS MAY not actually exist in the network as such and is 
only conceptually present for supporting the signalling generation. Complete TS MAY not be appropriate 
for actual transmission over the air. 

Regionalized TS: partially available TS where not all signalled services are actually present 

NOTE 1: We distinguish between the "global regionalized TS" (aka "global TS") where only the common services 
are present, and the "local regionalized TS" (aka local TS) where only the common services and a fraction 
of the local are present. 

NOTE 2: Low Latency Service may be present in both, the "global regionalized TS" and the "local regionalized 
TS". 
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Partially available TS 
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Figure 4: Partially available TS tree definition 

Low Latency adapted TS: TS with introduced RL gaps between the RL Service(s) for the Low Latency Service 

NOTE 1: Each TS, the Partially Available, the Complete and the RegionaUzed TS may be Low Latency adapted. 

NOTE 2: A TS is Low Latency adapted before a Low Latency Service can be included without loss of RL Service 
payload data. 

NOTE 3: Low Latency adaptation neither adds nor removes any payload to/from the RL Service, but included Null 
TS packets. This changes the data rate of the TS. 

NOTE 4: Low Latency adapted TS is input into RL path of modulator as detailed in clause D.2.2.2 of [9]. 
RL Service 
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Figure 5: Low Latency Adapted TS 

IP/MAC notification service: DVB service with a component carrying one or more INT sub_tables 
IP/MAC partially available notification service: IP/MAC notification service that is partially available 
MPE-IFEC section: private section as specified in EN 301 192 [2] 

3.1.3 Tables 

NIT_actual: NIT sub_table describing the actual deUvery network. NIT_actual has table_id value 0x40 
NIT_other: NIT sub_table describing the other delivery network. NIT_other has table_id value 0x41 
INT deferred notification NIT: NIT sub_table containing a linkage_descriptor with linkage_type OxOC 
INT notification NIT/BAT: NIT or BAT sub_table containing a linkage_descriptor with linkage_type OxOB 
IP/MAC notification table: sub_tables as defined in EN 301 192 [2], clause 8.4.3 
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3.1 .4 Signalling structures 



3.1.4.1 



For NIT & BAT 



IP/MAC notification link structure: structure defined in EN 301 192 [2], clause 8.2.1 and used in the direct 
linkage_descriptor inside BAT or NIT, when linkage_type is set to OxOB 

Deffered IP/MAC notification link structure: structure defined in EN 301 192 [2], clause 8.2.2 and used in the 
deferred linkage_descriptor inside NIT, when linkage_type is set to OxOC 



3.1.4.2 



For SDT & PMT 



IP/MAC notification info structure: structure defined in EN 301 192 [2], clause 8.3.1 and used by the PMT related to 
the IP/MAC notification service inside the data_broadcast_id_descriptor, when data_broadcast_id is set to OxOB 

multiprotocol encapsulation info structure: structure defined in EN 301 192 [2], clause 7.2.1 and used by SDT in 
data_broadcast_descriptor and PMT in data_broadcast_id_descriptor, when data_broadcast_id is set to OxOB 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

BAT Bouquet Association Table 

CAT Conditional Access Table 

CRC Cyclic Redundancy Check 

DVB Digital Video Broadcasting 

EIT Event Information Table 

ES Elementary Stream 

FEC Forward Error Correction 

FFS For Further Specification 

EFT Fast Fourier Transform 

INT IP/MAC Notification Table 

IP Internet Protocol 

IPDC IP Datacasting 

IPv4 Internet Protocol, version 4 

IPv6 Internet Protocol, version 6 

LL Low Latency 

Mbps Mega bits per second 

MPE Multi-Protocol Encapsulation 

MPEG Moving Picture Expert Group 

MPE-IFEC MPE Inter-burst Forward Error Correction (DVB-SH) 

NIT Network Information Table 

OFDMA Orthogonal Frequency Division Multiple Access 

PAT Program Association Table 

paTS partially available TS 

PID Packet IDentifier 

PMT Program Map Table 

PSI Program Specific Information 

RL Regular Latency 

RST Running Status Table 

SDT Service Description Table 

SEN Single Frequency Network 

SH Satellite to Handheld 

SHIP SH frame Information Packet (DVB-SH) BROADCAST 

SI Service Information 

ST Stuffing Table 

TDM Time Division Multiplex 

TDT Time and Data Table 

TOT Time Offset Table 

TPS Transmission Parameter Signalling 
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TS 
TSDT 



Transport Stream 

Transport Stream Description Table 



4 PSI/SI IG for DVB-SH Systems 

4.1 Introduction to PSI/SI (informative) 

PSI/SI usage for DVB-SH does not significantly deviate from the PSI/SI usage for DVB-H as specified in 
TS 102 470-1 [8]. In the particular case of SFN or in non-SFN when exactly same capacities are available on the 
different frequencies, the DVB-SH and DVB-H PSI/SI usages match on large extents so that they can even share the 
same introduction clauses 4.1.1 and 4.1.2. 

In that latter case, the difference between DVB-SH and DVB-H mainly relies on the usage of descriptors needed for 
supporting signalling of SH novelties such as physical parameters (via SH_delivery_system_descriptor), MPE-IFEC 
(via time_slice_fec_identifier_descriptor) and their usage in the NIT and INT. These differences are described in the 
relevant clauses 4.4 (descriptors) and 4.6 (SI Tables). 

However, a new concept called "content regionalization" can be provided by SH on the same TS (then called a 
"partially available TS") in some specific non-SFN modes (SH-B and SH-A non-SFN). The principle is that the actually 
transmitted content in the TS varies depending on the transmission location (cell_id) while preserving the SI, therefore 
simplifying hand-overs between satellite and terrestrial regions because the terminal does not need to parse SI each and 
every time. This concept therefore induces some impact on the PSI/SI side and needs special introduction in clause 4.2. 

4.1 .1 PSI/SI and DVB network (SFN and non SFN with same capacities 
on different frequencies) 

This clause is same as clause 4.1 in TS 102 470-1 [8]. 

4.1 .2 IP platform; IP flow and IP stream (SFN and non SFN with same 
capacities on different frequencies) 

This clause is same as clause 4.2 in TS 102 470-1 [8]. 

4.2 Content regionalization in SH networks (non-SFN with 
different capacities on different frequencies) (normative) 

This clause describes how content can be regionalized on a TS sent over a SH network on a hybrid frequency in a 
non-SFN context with different transmission capacities between satellite and terrestrial transmitters, while the latter are 
all SFN synchronized together. In such conditions, the terrestrial transmitters support different, and in general, increased 
capacity compared to satellite transmitter. Local content can therefore be injected in the different terrestrial cells in 
addition to the common satellite content repeated locally. 

In order to prevents the terminal from parsing non-real time signalling (the SI) each time it performs a hand-over 
between a satellite and a terrestrial cell, a common SI is generated and transmitted in all cells and has to be acquired 
only once, real-time signalling (PSI) being the only location-dependent signalling to be acquired at each hand-over. 

A "complete TS" is therefore defined in order to support SI unicity. Only the signalling part of the "complete TS" (to 
ensure unicity of signalling) SHALL be generated, data part of the complete TS (such as MPE data) is left to 
implementation. "Local TS" are the actual TS being modulated with the same SI as the "complete TS" but with their 
own specialized PSI. Since local TS are the ones to be actually modulated, these "regionalized TS" SHALL be fully 
generated in a mandatory way with the signalling and data. Therefore the interfaces between {adaptation; distribution} 
function on one side, and modulation on the other side is mandated, {adaptation; distribution} functions themselves are 
not mandated and left open to implementation. 
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4.2.1 TS construction using time-slice bursts, DVB and DVB-SH services 



4.2.1.1 



Generalities (normative) 



One particularity of SH networks is the possibility to provide content regionalization inside the same TS in the non-SFN 
case (global signal is not modulated on the same frequency as the local signal). The regionalization concept is 
summarized in Figure 6. 



TS_id 1 (all services^ 



Adaptation 

& 
distribution 




Mandatory for the signalling 



Left open to implementation Mandatory for the modulation 

Figure 6: Service regionalization concept 



It can be seen in this figure that regionalization is performed in 3 main steps: 

• Step 1: A master "complete TS" is generated that signals all services on the PSI/SI level. Therefore PSI/SI 
coherence is ensured between all regionalized TS. 

• Step 2: This "complete TS" is then distributed and adapted to all modulators of the system (the common and 
local ones). The adaptation function consists mainly in filtering out the content that does not pertain to the 
location. The order of operations performed during this step is left open to implementation. Different 
approaches are possible for performing this step. 

One implementation illustrated in Figure 7 consists in "distributing then adapting". This approach is better suited for 
local re-multiplexing cases where more flexibility (and therefore more complexity) is required at the repeater level. In 
particular, advanced processing at section level can be done on the common satellite service repeated locally to avoid 
duplication of unnecessary MPE-IFEC sections, or enable replacement of satellite MPE-IFEC sections with 
complementary sections: 

• The "complete TS" is distributed to the different repeaters as it is with all services actually included. Individual 
services are transported only once over the distribution network. Content can be distributed over a global or a 
local distribution network, depending on the coverage requirements. 

• Inside each repeater an adaptation function creates a "regionalized TS" that is syntactically correct and where 
all PSI/SI tables are re-multiplexed along with SHIP and MPE signalling. PSI/SI are however still coherent 
between all the "regionalized TS" (the SI being the same), therefore a receiver catching local regionalized TS 
can learn the unique SI, about non-present neighbour or foreign local services. 

• This regionalized TS is subsequently modulated. 
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Figure 7: "Distribute then adapt" approach 



Another implementation illustrated in Figure 8 consists in "adapting before distributing". This approach is better suited 
for cases where local re-multiplexing can be avoided and where a central head-end can pre-process all signalling: 

• The "complete TS" is adapted inside the head-end where all "regionalized TS" individual or complete parts 
can be pre-computed in the form of individual or group of DVB/SH service(s), further called a 'part'. 

• Each part is distributed to the relevant repeaters. Different distributions means are possible. As an example, 
each part could be carried within a different PID (PID_1 for "global regionalized TS" part common to all 
repeaters, PID_2 for "local regionalized TS" specific part to region 1, PID_3 for "local regionalized TS" 
specific part to region 2. . .). A local repeater in region X will then need to select PID_1 and PID_(Xh-1) to 
create the complete "regionalized TS". If more transport granularity is required between two regions, more 
PID can be used to factorize the parts in common between different regions. More details on such a transport 
implementation is out of scope of the present document. 

• Inside each repeater the modulator is in charge of stacking the different parts by appending them for 
subsequent modulation. 

• The head-end can be split into a global and a local head-end where most of the common signalling is being 
processed at the central head-end and only the local signalling is being processed in the local head-end. More 
details on this approach is out of scope of the present document. 
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Figure 8: "Adapt then distribute" approach 



• Step 3: the regionalized TS are modulated. The modulator located behind the adapter receives canonical TS. 
Depending on the cell to which they belong, these modulators therefore receive only a fraction of the 
"complete TS" services inside the "regionalized TS" with a coherent signalling between all the different 
"regionalized TS". SHIP is used to synchronize the modulators together. 

NOTE 1: Regulatory constraints MAY impose all local repeaters to repeat the common services. In addition to 
these common service, local repeaters MAY also modulate local contents specific to the cell to which 
they belong. 

Each "regionalized TS" is a syntactically correct TS so that a receiver receiving this only TS can process the signal and 
learn on a service absence and its regionalization. In some circumstances, the terminal can receive several "regionalized 
TS" from the same "complete TS" (for instance the common and one local ones). If the network configuration and the 
terminal capacity enable it, the two "regionalized TS" can be combined together to provide more reception quality on 
the common content. 

NOTE 2: This improvement is always optional, a terminal being always able to switch from one "regionalized TS" 
to another without benefiting from the complementary reception. 

Different options are possible for performing service filtering during adaptation; this can be done at SH or DVB service 
layer: 

• At SH services layer, the adapter selects one or several SH services from the "complete TS" as signalled by the 
SHIP carried inside each SH frames. The downstream repeater will then modulates the only selected SH 
services and will align them within the SH frame. At the receiver side, these SH services are identified by the 
EFRAME sequence number. For the common services, the quality MAY be improved by recombining the 
EFRAMES from both "regionalized TS" in the terminal using code diversity. These principles are more 
detailed in clause 4.2.1.3. 

• At DVB service layer, the adapter selects only the relevant Elementary Streams from the "complete TS". 
PSI/SI tables are recomputed. At the receiver side it is then not possible to combine the EFRAMES of the 
common content from the different paths since the individual bits received on satellite and terrestrial paths 
MAY differ. However, some combination is still possible at MPE and MPE-IFEC section level: 

For the common services, missing MPE sections on one path COULD be received on the other path. 

Additionally if MPE-IFEC is used, different MPE-IFEC sections COULD be received via the different 
paths and combined inside the same decoding matrix by the terminal. This code combining option is 
FFS. 
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4.2.1.2 



Impact on PSI/SI (normative) 



In all cases PSI/SI homogeneity is ensured since the same complete TS identification is used on all regionalized TS (in 
particular SI are unique). The DVB service granularity is used to provide consistent regionalization information 
whereby one DVB service MAY belong to, one (e.g. one local content cell), several (e.g. several local cells) or all cells 
(e.g. common content case). In Figure 9, a possible logical DVB object hierarchy is presented: 

• One IP encapsulator delivers the complete "complete" TS where all (time-sliced) services are present, usually 
in individual elementary streams. 

• These elementary streams are mapped in DVB services that are logically connected to individual cells: the 
presence of one DVB service in one cell is signalled via the SDT service_availability_descriptor. Therefore a 
DVB service is a logical container for regional distribution. 

• If the content regionalization is performed at the SH service layer, the DVB services are in addition mapped on 
SH services using SHIP signalling so that adapters can perform filtering using SH frames and produce a 
"regionalized TS" (either local or common) by removing those SH services from the "complete TS" that are 
not present in the cell, and keeping those that are present. Possible update MAY occur on the local SH services 
(section header real-time parameters adaptation, PSI reprocessing, SHIP update. . .). 

• If the content regionalization is performed at DVB service layer, the DVB services are simply removed from 
the "complete TS" at the level of the elementary stream. In addition a number of operations are performed 
(section header real-time parameters adaptation, PSI/SI reprocessing, SHIP update...) and the common service 
can be further optimized since no physical combination is requested between the satellite and the terrestrial 
paths. 

• If Low Latency Services are used, the TS of the corresponding Regular Latency Service must be Low Latency 
adapted before both services can be multiplexed. This processing is done sequentially according to the 
mux_assoc-vector (refer to [6]). For each codeword assigned RL (according to mux_assoc -vector), 8 TS 
packets from the Regular Latency Service are taken, for each codeword assigned to LL, 8 NULL TS packets 
are inserted. Also refer to Figure 5. 



TS 



DVB service 1 



DVB service 2 



DVB service 3 



Component 1,1 Component 1,2 Component 1,3 I Component 2,1 Component 2,2 



Component 3,1 Component 3,2 



DVB-SH service 1 



DVB-SH service 2 



DVB-SH service 3 



Figure 9: Transport stream with regionalized content and related DVB object hierarchy 
4.2.1 .3 Filtering at SH service layer (informative) 

Due to the specificity of SH service filtering, a special zoom is given on this case. When the filtering is performed at SH 
service layer, the "complete TS" different layers look like Figure 10. 
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Figure 10: Content regionalization signalling 



It can be seen Figure 10 that: 



• Time-slicing signalling is done at the MPE level using the real-time parameters of the MPE headers. 
MPE-IFEC sections MAY also be carried. 

• MPEG2 TS level signalling is done via the PSI/SI; for instance the PMT, PAT and SDT signal to which DVB 
services the different elementary streams belong and in which cells the DVB services are located. In the 
example of Figure 10, the elementary streams CiJ of DVB service "i" share the same colour and are timely 
grouped together. They will be modulated on the same cells. 

• DVB-SH level signalling is done by the SHIP packets inserted in each and every SH frame; the SHIP packets 
signal what and when the next SH service starts in the next SH frame. When content regionalization is 
performed, the DVB services MUST match the SH services, id-est a DVB service MUST be completely 
located inside a SH service. 

Based on this signalling, the SH service filtering is performed by the {adapter; distribution} differently depending on 
the cell where the repeater is located and on the distribution method: 

• In all cases, the global {adapter; distribution} keeps only one DVB service (e.g. the service 1) and distribute it 
to all repeaters. 

• In the "transmit and adapt" method, one local adapter keeps the common service by regulatory constraint 
(service 1) and possibly one or more additional local service(s) (e.g. service 2 or 3) that are transmitted to the 
modulator so that this latter can transmit both services as exemplified in Figure 1 1 . 

• In the "adapt and transmit" method, one local adapter keeps the complementary local service(s) (e.g. service 2 
or 3) and distributes them in individual parts to the modulator where they are combined with the common part 
in order to form the "regionalized TS" as exemplified in Figure 12. 

This is described in more details below. 
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Figure 1 1 : SH service filtering principle using "transmit and adapt" method 
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Figure 12: SH service filtering with "adapt and transmit" method 
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The IP encapsulator constitutes the "complete TS" with following design criteria: 

SHIP signals SH services for regionalization purpose, at least one SH service for each region. The SH 
services are repeated with a specific repetition_interval. SH services are timely grouped so that all SH 
services MUST be found during each repetition_interval. 

As required for subsequent per-SH frame alignment, SH services MUST be aligned with SH frames 
following these rules: 

■ Beginning of the first SH service of one region MUST match beginning of a SH frame. 

■ However if there are more than one SH service in this region, the remaining SH service(s) are not 
required to match this criteria. 

■ As a consequence repetition_interval is a multiple of the SH-frames duration used in the global 
"regionalized TS". 

There is one SHIP per SH-frame whose size depends on the actual modulation parameters: 

■ SH frame capacity in the common SH service is based on the global modulation; this capacity is 
computed from the modulation characteristics (see for instance [6], table 5.11 for OFDMA case 
and [6], table 5.12 for TDM case) and the chosen code rate and is expressed in units of EFRAMES 
that carries 8 MPEG2 TS. 

■ SH frame capacity in the local SH service is a complementary capacity that comes in addition to 
the global capacity. Therefore SH frame size MAY differ between the common and local SH frame 
capacities. 

Note that the above time-slice bursts need not be aligned with this repetition_interval. However in case 
power saving is sought with a class 2, time-slice burst MUST be aligned with SH frames as 
recommended in [7], clause 7.2.3.3.1. 

The {adapter; distribution} create and distribute the "regionalized TS" for subsequent modulation by the 
modulator: 

To create the global "regionalized TS", the {adapter: distribution} has to excerpt the common SH service 
(e.g. service 1). A valid SHIP is already present in every SH frame constituting the SH service that can 
be used by the global modulator to synchronize the global SH frame with the local ones. 

To create the local "regionalized TS", the {adapter; distribution} has to excerpt the SH service 1 and the 
local SH service (e.g. SH service 2) and merge both together. The merging of the global and local SH 
frames is done in such a way that only one valid SHIP is present in every SH frame, enabling the 
modulator to synchronize the local SH frame with the global SH frame and with other repeaters of the 
same terrestrial SFN cell. The merging is therefore achieved at the level of each and every SH frame, 
each SH frame bearing a common part that can be code-combined between the two "regionalized TS", 
and a local part that is present only on the local "regionalized TS" (see clause 4.2.1.4 for more 
information on receiver behaviour). 

The modulator receives a valid SH frame: 

The resulting SH frame is received at a bit rate equal to the actual radio capacity. Therefore, thanks to the 
SHIP, the modulator can apply the usual processing for synchronization. 

Note that the terrestrial modulator will receive two SHIP in each SH-frame, one in the common part and 
one in the local part, only one (the one in the local part) being valid. 

This synchronization is important since both SH frames on the two "regionalized TS" need to be aligned 
by the two modulators before transmission. The procedures for doing such an alignment can be found in 
clause [7], clause 7.2.3.4. 
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4.2.1 .4 Receiver behaviour with SH service layer filtering (informative): 

First at cold start, terminal acquires PSI/SI. In particular, the terminal resolves the global path for the elementary stream 
of interest. It also resolves availability of the DVB service where the elementary stream is located. Additionally, the 
terminal MUST acquire via the received SHIP the map of the SH services. The structure of the SH services is repeated 
regularly in the common part using service_synchronization_function (see [6], clauses A.4.9 and 4.2.10.2.5). 

We assume that the receiver has acquired non-real time information whereby the receiver has an exact map of SH 
services and DVB services availability per cell_id: 

From SHIP cell_id and servicejocalization functions, the receiver can map on which cells local SH services 
are being transmitted (see clause 4.10.2 for more details). We assume in the following that there is a unique 
common SH service with an id set to '0'. 

From SDT service_availability_descriptor, the receiver has knowledge of the availability of DVB services on 
each cell (see clause 4.4.3). 

In this example, we assume the receiver is interested by a service carried within SH service '0': 

If the receiver can receive both "regionalized TS": 

On satellite signal, receiver wakes up at time signalled by previously received delta-t whereas on 
terrestrial signal, receiver wakes up at time signalled by updated delta-t (see clause 4.3). 

Receiver coarsely aligns each received SH-frame since SH frames are timely aUgned (see [6], 
clause 5.5.2.2). 

Receiver localizes common SH service '0' on both "regionalized TS". This can be achieved by different 
means: 

If the receiver maintains a precise time and frequency clock, it can predict start of the SH frame and 
SH service (see [7], clause 7.5.3.3). 

When the first EFRAME has been decoded, the receiver can compare CBCOUNTER_SH that is 
related to the SH service number (see [6], clause 5.1.2). 

When a SHIP is received, it can signal the start of a service in the next SH frame. If the SHIP 
indicates the start of service '0' in the next SH frame, the receiver can derive immediately the 
beginning of the common service. 

Inside the SH service '0', EFRAMES can be compared one to one using CBCCOUNTER_FB. 

Receiver decodes current EFRAME with soft bits information coming from both modulation paths as 
explained in [7], clause 7.2.2.3. 

If the receiver can receive only one "regionalized TS", receiver only decodes EFRAMES individually: 

Receiver wakes up are time signalled by delta-t. See clause 4.3 for more information. 

Receiver decodes current EFRAME with soft bits information coming from a unique modulation 
scheme. 

Similar approach (as the reception of a unique "regionalized TS") would be applied for a local SH service. 

4.2.2 Filtering at SH service level 
4.2.2.1 Recommendations (normative) 

4.2.2.1.0 Introduction 

We give recommendation of the complete TS attributes in clause 4.2.2.1.1, then we describe how filtering is achieved in 
clause 4.2.2.1.2, then we give the result of the filtering in the form of the regionalized TS attributes in clause 4.2.2.1.3. 
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4.2.2.1.1 "Complete TS" attributes 

4.2.2.1.1.1 Introduction 

We describe first the common SH services then the local SH services attributes. 

4.2.2.1 .1 .2 Common SH service attributes 

4.2.2.1.1.2.1 Introduction 

NOTE: As a consequence of common service repetition in all "regionalized TS", the requirements applying to the 
common SH service are also valid for common SH services in all regionalized TS (see clause 4.1.2.1.3.1). 

4.2.2.1 .1 .2.2 Mandatory SHIP parameters 

Mandatory SHIP parameters are pertinent for the actual regionalized TS where this SHIP is valid. Since SHIP present in 
the common service MUST have a synchronization_id set to T and be valid for the satellite cell, the SHIP therefore 
conveys radio parameters corresponding to the satellite cell. 

NOTE 1 : SHIP having a synchronization_id set to '0' are valid for the terrestrial cells and therefore convey radio 
parameters corresponding to the terrestrial cell. They cannot be located in common SH service unless 
there is no satellite cell at all. 

NOTE 2: If different radio parameters are to be used with the same TS (for instance transmitting the TS over 

different satellite cells while maintaining the same bit rate, e.g. by modifying the EFT in DVB-SHA) only 
one set of real-time parameters can actually be fixed in the SHIP. However the SHIP in the regionalized 
global TS can be updated to reflect the updated SHIP values inside each cell. 

NOTE 3: Since the complete TS is not made for actual modulation (only the local TS is made for) there is no real 
consequence on the fact that all radio parameters are not reproduced in the SHIP real time parameters. 

4.2.2.1 .1 .2.3 Optional SHIP parameters 

In general, optional functions SHOULD be conveyed in SHIP located in the common SH service. In particular, 
functions describing content localization such as cell_id, servicejocalization, service_synchronization MUST be 
located in the common SH service. Some exceptions are listed in the local service attribute (clause 4.2.2.1.1.3.2). 

If an optional function conveyed by the SHIP packet spans several successive SHIP, the function SHOULD be 
completely described within current common service or, otherwise stated, part of the function SHALL not be 
distributed in other services than the common one. 

If it is not possible to convey the function within the current common service, then the following SHIP conveying the 
remaining of the function SHALL be located in the next iteration of the common service. Therefore no part of an 
optional function starting in the common service SHALL be located in the local part. 

The procedure for supporting transmission of optional SHIP parameters over several SHIP packets is defined in 
clause 4.10.2.1. 

4.2.2.1.1.2.4 PSI/SI tables 

When present, the BAT, TOT, UNT, CAT, TSDT MUST be located in the common SH service only. 

The NIT, SDT, TDT SHALL be sent in the common SH service only. 

Other tables (EIT, RST, ST) are ignored and SHOULD not be transmitted. 

The INT SHALL be sent in the common SH service only. 

All tables sent in the common service SHALL be received in all cells. 



£75/ 



25 ETSI TS 1 02 470-2 V1 .2.1 (201 1 -09) 

PAT and PMT must be inserted in the common SH service according to regular repetition frequency. Their content is 
according to clause 4.2.2.1.2.2: 

• The PAT MUST signal all DVB services present in the complete TS. 

• All PMT corresponding to DVB services present in the complete TS MUST not be void. 

4.2.2.1 .1 .3 Local SH service attributes 

4.2.2.1 .1 .3.1 Mandatory SHIP parameters 

Mandatory SHIP parameters are always pertinent for the actual regionalized TS where this SHIP is valid. Since SHIP 
present in the local service MUST have a synchronization_id set to '0' and be valid for the terrestrial cell, the SHIP 
therefore conveys pertinent radio parameters corresponding to the terrestrial cell. 

NOTE 1: SHIP having synchronization_id set to '1' do not belong to a local SH service but to the global SH service, 
are not valid in the regionalized TS and are to be ignored with regards to their conveyed mandatory 
parameters. 

NOTE 2: If there are different terrestrial radio parameters but leading to same bit rates (such as EFT size 

variations), only one set of parameters can be signalled in the mandatory parameters of the local SHIP of 
the complete TS. Local variations are to be reflected in the local SHIP of the different regionalized TS 

(see clause 4.2.2.1.2.1). 

4.2.2.1 .1 .3.2 Optional SHIP parameters 
Optional functions starting within a local SH service are: 

• service_synchronization_function: 

the start flag of the service_synchronization_function MAY be used in a SHIP external to common SH service. 

• Other functions specific to the local transmitters belonging to the cell where the local service is present 
(transmitter_*). 

All those functions MUST be transmitted in the current SHIP. 

4.2.2.1.1.3.3 PSI/SI tables 

SI tables MUST be signalled according to repetition intervals. Their content is according to clause 4.2.2.1.2.2. 

4.2.2.1.2 Filtering processing 

4.2.2.1.2.1 General procedure 

The filtering at SH service layer consists in: 

• Selecting those SH services from the "complete TS" that need to be kept in the "localized TS", e.g. based on 
SHIP signalUng (see [6], clause A.4.9). 

• Extracting the corresponding MPEG2 TS packets including MPE, MPE-FEC, MPE-IEEC, SHIP, PSI/SI, 
NULL. 

• Updating the MPE / MPE-IEEC headers real time parameters of the selected ES, in particular the delta-t: 

delta-t for the common services in the global and local "regionalized TS" being based on the repetition 
interval and global "regionalized TS" bitrate; 

delta-t for the local services in the local "regionalized TS" being based on the repetition interval and local 
"regionalized TS" bit rate; 

see clause 4.3 for more details. 
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• Creating or updating the SHIP packets inside the common and/or local SH service to signal the new 
synchronization_time_stamp value based on the actual "regionalized TS" (whether global or local) bit rate, and 
the new service arrangement in the synchronization function. 

NOTE: If there are different radio configurations not impacting the bit rate (such as different FFT sizes), the radio 
parameters of the SHIP need to be aligned in the corresponding areas. For instance in two different 
terrestrial celllDs, different FFT MAY be used resulting in different mandatory parameters. 

• Creating or updating the PSI such as the PAT and the PMT to reflect the list of local DVB services that are 
present on the local SH service only (see clauses 4.2.2.1.2.2 and 4.5). 

4.2.2.1.2.2 PSI/SI scope 

A DVB-SH receiver MUST consider the received SI as valid for all other "regionalized TS" of the same TS. 

On the contrary, a DVB-SH receiver MUST consider the PSI of the current "regionalized TS" as only valid for the 
current TS: 

• Even if all PMT of the complete TS services are present, the only PMT of the local (and common) DVB 
services actually present are valid, the other PMT being void. 

• As an exception, the PAT MAY be considered as valid for all "regionalized TS". 
A procedure is given to illustrate how PMT MUST be interpreted by the DVB-SH receiver: 

• The PMT MUST be monitored during an update period equal to a SH frame duration before being considered 
as updated. 

• During this update period, a DVB-SH terminal receiving a void PMT SHALL NOT conclude that the service 
is not present but that this DVB service is not globally available. 

• All received PMT during the update period MUST be considered. Only when the update period has ended that 
any conclusion can be drawn. 

• Therefore at the end of the update period the following events MAY occur for each DVB service signalled by 
a PMT: 

If a non-void PMT for the corresponding DVB service has been received, then the corresponding ES of 
the DVB service are actually conveyed in the regionalized TS. 

If only void PMT for the corresponding DVB service have been received, then no ES of the DVB service 
is actually present in the "regionalized TS". 

• The following situation CAN therefore occur: 

Those DVB-SH receivers receiving only the global "regionalized TS" will get: 

■ For common DVB services: complete PMT within the global SH service. 

■ For local DVB services: void PMT within the global SH service. 

NOTE 1: DVB-SH receivers will therefore have no information on the DVB services that are not present since all 
corresponding PMT are void. 

Those SH receivers receiving only the local "regionalized TS" will get: 

■ For common DVB services: complete PMT within the common SH service; 

■ for local DVB services: void PMT within the common SH service; 

■ for local DVB services: complete PMT within their corresponding local SH services. 

NOTE 2: DVB-SH receivers will consider the local ES as present based on existence of non-void PMT. 

PMT SHALL be updated when a change in the receiver situation occurs (change in regionalized TS reception 
conditions). 
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4.2.2.1.3 "Regionalized TS" attributes 

4.2.2.1.3.1 Common SH service attributes 

4.2.2.1.3.1.1 Data 

For the sake of code combining, all the bits of the common services MUST be identical in all regionalized TS. 

All adapters MUST keep the same number of MPEG2 TS packets from the common SH service. 

All adapters MAY modify MPEG2 TS packets provided that all adapters of the SH network perform the modification 
simultaneously and identically. 

MPE / MPE-FEC / MPE-IFEC section headers MUST be modified as follows: the delta-t must be updated to reflect 
change in bit rates and service distribution. 

4.2.2.1.3.2.1 Signalling 

Due to exact correspondence between common SH services in complete and regionalized TS, clause 4.2.2.1.1.2 apply. 
In addition, the following applies to the regionalized common SH services. 

• SHIP packets MUST be modified as to be valid for the global repeater: 

synchronization_time_stamp MUST be updated to reflect the new emission time of the next SH frame 
start due to the difference in bit rates between "complete TS" and global "regionalized TS"; 

SH service information MUST be modified to align with the service arrangement available on the global 
"regionalized TS"; 

pointer MUST be kept unmodified so that this information is correct for the global modulator. 

As a consequence, the SHIP packets MAY not be valid for the local repeaters: 

■ STS and pointer MAY therefore not be correct for the local modulators and these modulators 
MUST ignore them. 

■ SH service information MAY not be correct after filtering on the local modulators when a SH 
service following the common one is removed. 

■ To signal that SHIP MUST be ignored by local modulators but not by global, its 
synchronization_id MUST be set to "1" (see clause 4.10.1.1 for more details). 

• PAT SHALL list all programs and therefore all DVB services of the "complete TS": 

PAT of the "regionalized TS" SHALL NOT be modified compared to "complete TS". See for more 
details clause 4.5.1. 

• All PMT present in the "complete TS" SHALL be present in common part of the "regionalized TS". 

All DVB services of the "complete TS" have their PMT present in the "regionalized TS". 

PMT describing local DVB services SHALL be void (no elementary streams are announced in the 
ES_info_loop, ES_info_length is set to '0') while keeping the same version_number. See for more details 
clause 4.5.2. 

• Other PSI/SI tables MUST be kept unmodified since they MUST be generic for all cells. 

4.2.2.1 .3.2 Local SH service attributes 

4.2.2.1.3.2.1 Data 

All modulators belonging to the cell where the SH service is modulated MUST keep the same number of MPEG2 TS 
packets from the local SH service (and discard those SH services that are not present in the cell). 



£75/ 



28 ETSI TS 1 02 470-2 V1 .2.1 (201 1 -09) 

Modulators MAY modify MPEG2 TS packets provided all modulators of the current cell perform this modification 
identically and simultaneously on a given region. 

NOTE: Two sub-regions MAY actually transmit same content but with different radio parameters not modifying 
the bit rate such as FFT. In such a case it is recommended to formally distinguish the two regions on the 
infrastructure side, each having its own set of radio parameters. 

MPE/MPE-FEC/MPE-IFEC section headers MUST be modified as follows: the delta-t must be updated to reflect the 
change in bit rates and service arrangement. See for more details clause 4.3. 

4.2.2.1.3.2.2 Signalling 

SHIP packets from the local SH service are relevant but MUST be updated as follows: 

• synchronization_time_stamp MUST be modified to reflect the emission time of the next SH frame due to the 
difference of bit rates between the "complete TS" and local "regionalized TS"; 

• service_synchronization function MUST be updated to signal the start of the common SH service in the next 
SH frame; 

• service_synchronization_function MAY list services present in the local TS. If this function does this listing, 
only the common and current local service(s) are listed in their sending order, all services being not 
transmitted in this local TS MUST not be listed (see clause 4.10.2.5); 

• pointer MUST not be updated; 

• synchronization_id MUST be set to '0' to indicate that this SHIP can be used for synchronization by the local 
modulator (see clause 4.10.1.1). 

NOTE 1: SHIP packets in the common SH service are irrelevant for terrestrial repeaters (synchronization_id is set 
to '1'). 

PAT SHALL not be repeated and therefore SHALL be discarded if present in the local SH service. 

NOTE 2: PAT of the common SH service can be used by the receiver. 

PMT of common services and non-present local services are not repeated and MUST be discarded from the local SH 
service. Therefore only the PMT of the DVB services present in the local SH service SHALL be present. 

NOTE 3: PMT of the other DVB services (common and other local) can be found in the common SH service. 

Other PSI/SI tables MUST NOT be modified. 

4.2.2.2 Example (informative) 

Please refer to Figure 1 1 . 

At the global modulator, only the common DVB/SH service MUST be kept: 

• The time-slicing information MUST be always correct and MAY be used by the receiver for power saving 
purposes. 

• Only SHIP with synchronization_id set to '1' MUST be used: 

SH service 'next start' MUST be valid (signalling service '1' start); 

synchronization_time_stamp MUST be valid and can be used by the modulators for synchronization 
purpose; 

The SHIP pointer MUST be valid. 

• The PSI/SI MUST be valid. 
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At a given local modulator, the common DVB-SH service MUST be kept along with one or several local DVB-SH 

services: 

• delta-t information signalled by MPE MUST be always correct (with some adjustment for the common 

services, see clause 4.3). 

• Only SHIP packets with synchronization_id set to '0' MUST be used: 

The SH service 'next start' MUST be valid. 

The synchronizaton_time_stamp MUST be valid. 

The pointer MUST be valid. 

• SHIP with synchronization_id set to '1' MUST be ignored; therefore there is only one valid SHIP per SH 
frame. 

• The PSI/SI are always correct. 

While receiving a global "regionalized TS" or a local "regionalized TS", the receiver will rely on the only delta-t 
signalled by the MPE headers to perform power saving (see clause 4.3 for more details). 

4.2.3 Filtering at TS layer 

TS layer filtering MAY or MAY not be performed using underlying SH service structure. Therefore only reference to 
DVB services SHALL be done in the following although SH services MAY also be used. 

4.2.3.1 Recommendations (normative) 

4.2.3.1.1 "Complete TS" attributes 

BIT, RST, ST are ignored and SHOULD not be transmitted. 

4.2.3.1.2 Filtering processing 

The filtering at TS layer consists in: 

• Selecting the TS packets belonging to the target DVB service(s). 

• Updating the MPE / MPE-IFEC headers real time parameters of the selected ES, in particular the delta-t. 

• Updating the SHIP packets to signal the new DVB-SH service sequence (if present) and the new 
synchronization_time_stamp/pointer values. 

• Updating the PAT and PMT tables to reflect the ES actual presence. 
To perform rate matching, NULL MPEG2 TS packets MAY be inserted. 

4.2.3.1 .3 "Regionalized TS" attributes / local SH service attributes 

MPEG2 TS packets carrying elementary streams belonging to filtered-out DVB services are discarded. 

MPEG2 TS packets carrying elementary streams belonging to filtered-in DVB services are kept. 

MPEG2 TS packets carrying elementary streams belonging to filtered-in DVB services MAY be modified provided this 
update is done identically and simultaneously on all modulators of the cell. 

MPE/MPE-FEC/MPE-IFEC sections headers are updated as follows: delta-t must be updated to reflect the change in bit 
rates and service arrangement. 
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SHIP is modified as follows: 

• service_synchronization function: service_index is updated to reflect new service arrangement (if present); 

• mandatory parameters: synchronization_time_stamp and pointer are updated to reflect the change in bit rates 
and service arrangement. 

One SHIP is inserted in each SH-frame whose capacity is computed from the actual modulation and encoding 
parameters. 

PMT are constituted as follows: 

• Only the PMT corresponding to the DVB services present in the "regionalized TS" SHALL be present. 

• The regionalized PMT SHALL list all elementary streams present in this DVB service. 
The PAT lists PMT that are present in the "regionalized TS" only. 

The INT MUST not be updated. 

The other PSI/SI tables are not modified. 

4.2.3.2 Example (informative) 

The examples are strictly the same as at the SH service layer with the following improvements: 

• the SHIP "next service" indication is always correct (if SH service is used); 

• the PAT and PMT tables are not any more generic in the common part and no PMT SHALL be void. 

4.3 Multiprotocol Encapsulation (normative) 

Clauses 4.3 and 5.2 of [8] apply without any exclusion. In addition, the following applies when paTS is used. 

4.3.1 SH SERVICE FILTERING 

4.3.1 .1 Common DVB-SH service 

In the common DVB service, if SH service filtering is used, the delta-t inserted in the real-time parameters is computed 
with a repetition interval equal to the actual common DVB service repetition interval and a bit rate equal to the bit rate 
used for global "regionalized TS" modulation. This computation is unique for all modulators, including the local ones. 
The DVB-SH receiver receiving the common DVB-SH service on the global "regionalized TS" MUST apply the 
signalled delta-t without any modification. 

When the global and local "regionalized TS" do not have same bit rates, assuming stretch_factor to be the ratio between 
local and global "regionalized TS" bitrates (stretch_factor>l), the DVB-SH receiver receiving the common DVB-SH 
service on the local frequency MUST update the signalled delta-t using one of the two following methods: 

• Assuming the receivers knows the position of the MPE section within the current SH frame as equal to 
t(start_current_framejgi,j^[ j§;current_sect[p^^j j§), we can derive: 

A, the position of the MPE section within global TS: 
A=t(start_current_framejgi,j^[ .j.§;cur_sect[gj,jj[ jg)*stretch_factor. 

B, the position of the next burst within global TS: B=AH-delta_t. 

C, the position of next burst within local TS: C=frame_duration*floor(B/frame_duration;0) + 
[B-frame_duration*floor(B/frame_duration;0)]/stretch_factor. 

D, the updated delta_t: D=C-A. 
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Assuming the receivers does not know the position of the MPE section within the current SH frame, the actual 
delta-t cannot be know precisely and we need substract the highest possible correction from the signalled 
delta-t value to avoid the receiver to wake up too late. This highest possible correction happens when the MPE 
section is at the beginning of the current SH frame (so both sections arrive at the same time on global and 
local) and the burst starts at the end of the target SH frame. In that case the delta-t is too long by 
SH_frame_duration*(l-l/strech_factor). In the absence of MPE position knowledge within the SH frame, the 
delta-t needs then to be lowered by SH_frame_duration*(l-l/strech_factor): 



Af'= Af-cei7 



SH _ service _ duration ' 



1 



stretch _ factor 



lOms 



where and ceil(x)jQjjjj, gives the highest and nearest duration expressed in units of 10 ms. 



4.3.1.2 



Local DVB-SH service 



The DVB-SH receiver receiving the local DVB-SH service on the local frequency MUST apply the signalled delta-t 
without any modification. 

In the following, we give one example that illustrates the need to update the delta-t on the "local regionalized TS". 
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Figure 13: Example of MPE delta-t updating 

The green delta-t signalled by first section of burst CI, 2 can be used as it is since the durations between, respectively, SH frame start and MPE section, and SH frame 
Start and next burst start, are identical. 

The red delta-t signalled by last section of burst CI, 2 need to be updated before being used in the "regionalized TS" since, in that case, the durations between SH frame 
start and MPE section, and SH frame start and next burst start, are different. If not updated, the red delta-t would lead to a too-late wake up time. 
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4.3.2 TS LAYER FILTERING 

In TS layer filtering is used, the delta-t is computed on the actual "regionalized TS" with repetition interval being equal 
to the actual DVB service repetition interval and bit rate equal to the actual "regionalized TS" bit rate so that the 
DVB-SH receiver can process the delta-t signalling for all received services as usual. 



4.4 Descriptors (normative) 



The complete list of the descriptors, their use in different tables, and descriptor tags may be found in EN 300 468 [1] 
and EN 301 192 [2]. The list given in [8], clause 4.6 is fully applicable with the exceptions given hereunder. 

4.4.1 SH_delivery_system_descriptor 

SH_delivery_system descriptor can be found in [1]. 

The descriptor MUST be found in the NIT in the TS loop, where there is at most 1 descriptor for each TS. Its purpose is 
to precise, for a given TS, the main physical (modulation, code rate, interleaver. . .) parameters. In addition to the 
physical parameters, it also delivers basic information on diversity options, including MPE-IFEC if relevant. One 
should note that it lacks frequency information since the latter can be found in other descriptors inside the NIT. It differs 
significantly from previous terrestrial and satellite delivery system descriptors in the sense that it has been designed to 
accommodate a large variety of system configurations. Therefore its size varies depending on the chosen configuration. 

4.4.1 .1 Diversity mode 

The descriptor starts with a diversity_mode that indicates essential diversity options selected for this TS: 

When paTS is not activated, there is no difference of content (in terms of hard bits) between the TS modulated on 
(possibly) different frequencies. The principle is that same bit rates are used for transmission on all frequencies listed in 
the cell_frequency_link_descriptor (see clause 4.4.5) and same 'hard bits' (including PSI/SI) are being modulated on all 
these cells. This does not however mean that there is no diversity supported: 



• 



• 



In SEN configuration, diversity can be supported on the unique frequency at the receiver side at radio layer 
(e.g. using multiple radio combining). 

In non-SEN configuration, diversity can be supported at physical layer with complementary code rates. To 
detect that complementary modes are used, the modulation loop has to be checked. 



When paTS is activated, this means that there is different content being transmitted over the different frequencies (in 
terms of hard bits), including PSI/SI that MAY differ between the different cells where the TS is being transmitted. 
Diversity_mode details how these different contents can be used for diversity purpose. 3 main combinations are 
possible: 

• "EEC at physical layer": this case corresponds to the combination of soft bits for specific SH services (the 
common one) using the "code combining" technique described in [7], clauses 7.2.2.3.3 and 7.4. In addition to 
the case where same code rates are being used (similar to the non-paTS non-SEN case described previously), it 
MAY be possible to use different complementary code rates. 

• "EEC at link layer": this case corresponds to the possibility to provide diversity at the link layer, using MPE 
and MPE-IEEC sections (this latter case is EES). In this case SH services MAY not be used, however SH 
usage even in this case is recommended in order to provide a homogeneous synchronization scheme. 

• Both previous cases together. 
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All different diversity options are presented in Figure 14. 
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Figure 14: Diversity options 



4.4.1.2 



Modulation loop 



Then there is a loop on the modulation schemes. The number of iterations depends on the system configuration. In the 
simplest case, the SFN on one unique frequency, there is only one iteration describing an OFDMA modulation. When 
additional diversity and/or frequencies are added, the number of iterations increases. Some examples are given in the 
table hereunder. 

Table 1 : Examples of modulation iterations within SHdeliverydescriptor 



Case 


Description 


OFDMA 
modulation 


TDM modulation 


1 


SH-A SFN with 1 satellite 


1 





2 


SH-A SFN with satellite diversity 


2 





3 


SH-B with 1 satellite and same terrestrial scheme 


1 


1 


4 


SH-B with 2 satellite and same terrestrial scheme 


1 


2 


5 


SH-B with 1 satellite and different terrestrial 
schemes 


As many terrestrial 
cells 


1 



Among all these case, the 5 needs special explanations given below through the modulation ordering loop design rules 
and their usage with the NIT context. 
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Since the frequency is not included in the SH_deHvery_system_descriptor, special care needs to be given to the 
modulation ordering according to the following rules; 

• Satellite modulations: 

Satellites modulation are always the first, terrestrial are the last. 

When several satellite modulations exist, they are all positioned at the beginning of the list. 

• Terrestrial modulations: 

When terrestrial modulations are the same on all frequencies, one unique iteration MUST be done. 

When different modulation parameters exist in the cells that transmit the TS, then all unique modulation 
schemes MUST be listed, each modulation scheme being possibly applied to a group of cells, therefore 
avoiding to repeat redundant information (see clause 4.6.2.1.5 to understand how such redundancy is 
avoided). 

• Transition between satellite and terrestrial modulations in the loop: 

When TDM is used for the satellite modulation, the transition is clearly defined by the change in the 
modulation scheme since TDM can only be used for a satellite transmission. 

When OFDMA is used for the satellite modulation, there is an ambiguity in the transition since OFDMA 
is also used for terrestrial modulation. Therefore the transition MUST be defined via another mechanism 
which is the common_frequency_flag: 

■ if OFDMA modulation is used for satellite (SH-A mode), common_frequency flag SHALL be set 
to T for the relevant modulation scheme; 

■ if OFDMA modulation is used for terrestrial (all cases), common_frequency flag SHALL be set 
to '0'. 

The usage of this ordering in conjunction with cell_frequency_link_descriptor is explained in the NIT section 

(clause 4.6.2). 

Each element in the loop has a size that depends on the actual individual physical parameters, essentially if TDM or 
OFDMA modulation scheme is used, and if, and how the interleaver is configured. The design has been made the most 
compact possible when several modulation schemes are present, using the following rules: 

• When the interleaver is the same, it SHALL not be repeated after the first definition (interleaver_presence set 
to '1' for the first iteration, and '0' for the following). 

• More generally, when an interleaver_presence is set to '0', this means that the latest previously described 
interleaver MUST be used. This can be useful not only between the satellite and terrestrial modulation 
(previous case) but also between terrestrial modulations when different parameters other than the modulation 
are changed. 

• When the interleaver is of class 1, the short form SHOULD be used instead of the long form reserved for 

class 2. 

4.4.1.3 Usage restrictions 

Restriction 1: Non-canonical SH configurations: 

Some combinations MAY correspond to non-canonical SH configurations: for instance it is possible to configure a 
SH_delivery_system_descriptor with a unique TDM modulation. When this is the case, there is no modulation scheme 
of type Tin the modulation loop, only one or several modulation schemes of type '0'. All the necessary parameters 
required for knowing the TDM modulation scheme are included in the modulation structure of type '0' as shown in 
Table 2. 
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Table 2: No OFDMA modulation 



Parameter 


Source 


Example 


Polarization 


polarization 


polarization = '10' 
polarization = "circular left" 


Roll-off 


roll_off 


roll off = '10' 
"Roll-off = 0,15" 


Code rate 


Code rate 


code_rate = '0100' 
"Code rate = 1/3 standard" 


Symbol rate 


symbol_rate-^ [1], Table 1 1 2 
"roll off" column 


symbol rate = '01101' 

"Roll-Off = 0,15" 
"symbol rate = 155/36" 


Bandwidth 


symbol_rate^ [1], Table 1 1 2 "TDM 
bandwidth" column 


symbol rate = '01101' 
"TDM bandwidth = 5 MHz" 



Restriction 2: code combining: 

When code combining is used in non-SFN conditions, then several modulations are present in the loop (at least 2) and 
complementary code rates MUST be announced. For instance in SH-B configuration with complementary codes, the 
following SH_delivery_system is used (see Table 3). 
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Table 3: SHdeliverysystem descriptor in SH-B withi complementary code 



Syntax 


Nofbits 


elements 


Multi 




SH_delivery_system_descriptor(){ 










descriptor_tag 


8 




8 




descriptorjength 


8 




8 




descriptor_tag_extension 


8 




8 




diversity_mode 


4 




4 




reserved 


4 




4 




tdm_modulation_descriptor 


24 




24 




interleaver_descriptor_complete 


32 










ofdm_modulation_descriptor 


24 


1 


24 




interleaver descriptor partial 
} 


8 


2 


16 




total in bits 






96 


bits 


Total in bytes 






12 


bytes 


signaled in bytes 






10 


bytes 



DVB-SH tdm modulation 


_descriptor 




modulation_type 




1 


interleaver_presence 




1 


interleaverjype 




1 


reserved 




1 


ll_service_mode 




4 


polarization 




2 


roll off 




2 


modulation_type 




2 


code rate 




4 


symbol_rate 




5 


reserved 




1 


24 



set to "0" 
set to "1" 
set to "0" 



set to '1 000' CR=1/2 standard 



DVB-SH_ofdm_modulation_descriptor 




modulationjype 


1 


interleaver_presence 


1 


interleaver_type 


1 


reserved 


1 


II service mode 


4 


bandwidth 


3 


priority 


1 


constellation_and_hierarchy 


3 


code rate 


4 


guardjnterval 


2 


transmission mode 


2 


common_frequency 


1 


24 



set to "1" 
set to "1" 
set to "1" 



set to '1001' CR=1/2 complementary 



4.4.1.4 



Unequal bandwidth 



The SH_system_delivery descriptor can support different bandwidth between satellite and terrestrial links. In this clause 
we review how such unequal bandwidth is signalled. The usage of unequal bandwidth is currently not envisaged for 
SH-A MFN, therefore the only use case considered for unequal bandwidth is within SH-B. 

OFDMA modulation is given directly in the modulation structure of type T, say OFDMA_BW. 

TDM bandwidth is given via Table 1 12 of [1] by the symbol_rate value found in the modulation structure of type '0', 
say TDM_BW. 

NOTE 1 : The actual symbol rate value is derived from TDM_BW along with other OFDMA and TDM parameters 
present in the modulation loop according to the formula: 



. f. L^l + G/V BW TDM ^ 28 

Sr^DM = mt mt 32 * = * , 

^ l^ l + a J BW OFDM Bps OFDM j 896 



1 BpS _ OFDM ■ BW _ OFDM 
\ + GI 
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NOTE 2: In case of presence of several modulations of type '1', the first one should be used to retrieve 

OFDMA_BW. Note however that other could be used since only the OFDMA FFT is assumed to be 
variable between the different OFDMA modulations, other parameters such as bandwidth, modulation 
order, guard interval being assumed to be fixed for this TS (if this was not the case, the TDM symbol rate 
would not be able to match the different OFDMA configurations but only one, see for instance the 
example given in clause 4.6.2.1.5 in Table 5 for more details on multiple OFDMA configurations). 

NOTE 3: At the receiver side, the modulation loop needs to be fully parsed before calculating the TDM parameters. 

4.4.1 .5 Low Latency Interleaver 

The SH_delivery_system_descriptor can support low latency service insertion. It is possible to embed a LL multiplex in 
the existing long interleaver. The physical layer parameters are signalled in the SH_delivery_system_descriptor if 
LL_service_mode is unequal to zero. The LL puncturing pattern is derived from the LL_service_mode (see [1], 
clause 6.4.4.2). The low latency interleaver profile depends directly on the regular interleaver parameters which are in 
the same iteration of the modulation loop. The derivation is described in [6], clause B.L5. 

The service structure of the LL multiplex is given by the service_synchronization_function in the SHIP (see 
clause 4. 10.2.5) and the Signalling Field of a TDM SH-Frame (see [6], clause 5.5.2.2). Another representation is the 
multiplex association-vector (mux_assoc-vector), see [6], clause B. 1.4.4. 

4.4.2 time_slice_fecJdentifier_descriptor 

This descriptor identifies whether time-slicing and/or MPE-FEC and/or MPE-IFEC are used on an elementary stream. 
This descriptor is used to announce each time-sliced Elementary Stream. The descriptor is defined in [2], clause 9.5. 

When located in the first descriptor loop of NIT, the descriptor applies to all Elementary Streams within all Transport 
Streams within the DVB network. If located in the second descriptor loop of NIT, the descriptor applies to all 
Elementary Streams within the referred Transport Stream, overriding any time-slicing or EEC information from the first 
descriptor loop. 

If located in the platform descriptor loop of an INT, the descriptor applies to all Elementary Streams referenced within 
the table, overriding any time-slicing or EEC information from the NIT. If located in the target descriptor loop, the 
descriptor applies to all Elementary Streams referenced within the current iteration of the target descriptor loop 
following the appearance of the descriptor, overriding any time-slicing or FEC information from the platform descriptor 
loop and in the NIT. 

Note that the descriptor applies to Elementary Streams with stream_type 0x90. Other stream_type values may be 
specified later. 

The descriptor may appear more than once, in which case each new occurrence overrides previous occurrence(s). 



4.4.3 Service Availability Descriptor 



This clause specifies the construction rules of the service_availability_descriptor, for the actual or a neighbouring 

partially available Transport Stream. We assume 1 TS having at least 1 SH_delivery system_descriptor with a paTS in 

at least 1 network: 

• Step 1 : the NIT sub_tables in scope SHALL be all the NIT sub_tables announcing this Transport Streams on 
networks where the SH_delivery_system_descriptor signals a paTS. 

• Step 2: the total set of cells in scope SHALL be all the cell entries of cell_frequency_link_descriptors assigned 
to this TS in the NIT sub_tables in scope. 

• Step 3: in the SDT sub_table of the Transport Stream, for each service entry of the services_loop: 

Step 3.1: within the total set of cells, identify the subset of filtering cells (i.e. the cells on which the 
service is not available). 

Step 3.2: in case two cell entries or more share the same cell_id, while providing opposite availability 
information for the service (whether the cell descriptions of these cell entries are identical or not), the 
common cell_id value SHALL be added to the subset of filtering cells. 
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Step 3.3: if the subset of filtering cells is empty, continue to next service entry. 

Step 3.4: otherwise, include the service_availability_descriptor, as follows: 

either set availability_flag to 0, and list in the descriptor the cell_id(s) of the subset of filtering 
cells; or 

set availability_flag to 1, and list in the descriptor the cell_id(s) of the total set of cells that are not 
present in the subset of filtering cells. 

NOTE: Value of availability_flag could change for each inclusion of the service_availability_descriptor, in order 
for instance to produce the shortest list of cell_id(s) as possible in the descriptor. 

4.4.4 cellJist_descriptor 

4.4.4.0 Introduction 

This descriptor lists all the cells of the DVB network together with their cell_id. 

4.4.4.1 General requirements 

The descriptor appears in the first descriptor loop of a NIT sub_table describing an IPDC DVB-SH Network and the 
cell Hst MUST be complete. 

The following applies: 

• Due to the definition regarding the sign of latitudes and longitudes the south-western corner of the rectangle is 
specified. 

• In case of large list of cells exceeding the capacity of the cell_list_descriptor (a maximum of 25 cells can be 
listed in a cell_list_descriptor) and/or the capacity of the NIT sub-table section (of a maximum size of 

1 024 bytes), the descriptor MAY appear several times inside the NIT table. 

• The splitting rules as defined in [i.l], clause 4.1.11.2 apply in that case. 

4.4.4.2 Special case of satellite cells 

Cells corresponding to a satellite transmission are called beams. 

Their celljd is taken in the range [0;255] so that AND(cell_id;OxFFOO) = 0x0000. 

The descriptor also lists the locations and the extension of the listed cells. While the location of a satellite cell does not 
bring any complexity, the extension of an overflow current maximum values: 

• cell_extent_of_latitude is coded on 12 bits but with steps of 90 / 2^^; maximum value is therefore 1 1,25°. 
While cell_extent_of_latitude maximum values MAY be suitable for a pan-European satellite (+11°), these 
values fall short for a North American coverage (+12°). 

• cell_extent_of_longitude is coded on 12 bits but with steps of 180 / 2^^; maximum value is therefore 22,5°. 
While cell_extent_of_longitude maximum value MAY be suitable for a pan-European satellite (+20°), value 
for beam covering North America (+30°) or Middle East (+50°) are much more demanding. 

In order to signal values beyond the maximum, it is recommended to use the value '0'. Extension '0' therefore means that 
cell is of extension greater than the maximum allowable value. 

4.4.4.3 Special case of terrestrial cells 

Cells corresponding to a terrestrial transmission MUST have a cell_id of value greater than 255. Therefore AND 
(cell_id;OxFFOO) must differ from 0x0000. 
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4.4.5 cell_frequencyJink_descriptor 

4.4.5.1 General requirements 

This descriptor lists all the frequencies used in transmission of a multiplex within the DVB network. It gives a complete 
list of cells and identifies the frequencies that are in use in these cells for the multiplex described. 

The following applies: 

• It can appears more than once in each iteration for which there is a SH_delivery_system_descriptor when the 
list of cells exceed the capacity of the descriptor (a maximum of 36 links can be listed in a 
cell_frequency_list_descriptor) and/or the capacity of the NIT sub-table section (of a maximum size of 

1 024 bytes), or when there are different groups of cells to be attached to different modulation schemes 
(see clause 4.6.2.1.5). 

• The splitting rules as defined in [i.l], clause 4.1.11.2 apply in that case. 

• The list of frequencies is complete. 

4.4.5.2 Special case of frequency diversity: 

When diversity of frequency is used in non-SFN configurations, the following ordering rules apply: 

• Satellite cells are listed first, terrestrial cells are listed last. 

4.5 PSI tables (normative) 

4.5.1 Program Association Table (PAT) 

4.5.1.1 Introduction (informative) 

Program Association Table (PAT) provides the correspondence between a program_number and the PID value of the 
Transport Stream packets that carry the DVB service definition. The program_number is the numeric label associated 
with a DVB service. The overall table is contained in one or more sections. It may be segmented to occupy multiple 
sections. 

A DVB network transmits the PAT on every Transport Stream. The PAT contains no descriptors. The program loop 
within PAT contains information about each DVB service within the actual Transport Stream: 

If the program_number 0x0000 is announced, the corresponding network_PID field is set to 0x10. 

The program_number of each DVB service available within the Transport Stream is announced. The 
corresponding program_map_PID indicates the PID of the PMT sub_table for the DVB service. A PMT 
sub_table is carried within an Elementary Stream with PID value between 0x0020 ... OxlFFE. 

The PAT table does not contain multiple iterations of the program loop with the same value of the 
program_number field (i.e. each program_number is announced only once). 

4.5.1.2 Requirements (normative) 

The following requirements apply to all cases: 

• PAT is always delivered in the Elementary Stream with the PID 0x0000. 

• For bit rate optimisation reasons, all Elementary Streams used to carry IP streams of a particular IP platform 
SHOULD be carried by a single DVB service unless paTS is used. 

• DVB-SH Network SHALL transmit PAT on each Transport Stream of the DVB network. The repetition 
period of all PAT sections is RECOMMENDED to be SH_frame_duration ms or lower. 
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• If a DVB-SH Receiver is receiving an IP stream, the following applies: 

Receiver SHALL detect changes in the PAT table (version number field). 

In connection with receiving a burst, Receiver SHALL check for a new version of the PAT during on- 
time of the time-sliced Elementary Stream. Receiver MAY ignore PAT filtering during the off -period of 
the time-sliced Elementary Stream. 

The following requirements apply to cases where the TS is of paTS nature at SH service layer: 

• The PAT SHALL list all DVB services. This applies to the common DVB service but also to all local DVB 
services, including those that are not present in the cell. 

• The PAT SHALL be present in the common SH service and SHALL not be present in the local SH services. 

• A PAT table section shall not span two successive SH services. One PAT table section SHALL end before the 
end of the current SH service. 

The following requirements apply to cases where the TS is of paTS nature at TS layer: 

• The PAT SHALL list only those DVB services that are actually being sent on the paTS, keeping program_map 
PIDs that have been filtered-in, removing those that have been filtered out. The filtered-in program_numbers 
as well as the program_map_PID SHALL not be modified. 

4.5.2 Program Map Table (PMT) 

4.5.2.1 Introduction (informative) 

The Program Map Table (PMT) provides mappings between program numbers and the program elements that comprise 
them. A PMT sub_table announces the mapping for a single DVB service. Within a Transport Stream, a PMT sub_table 
is identified by the program_number. A PMT sub_table is also referred to as a "program definition". The PMT is the 
complete collection of all program definitions (i.e. all PMT sub_tables) for a Transport Stream. 

The program_number of each DVB program should be unique within the network. The PMT sub_table for a particular 
DVB service is transmitted on the same Transport Stream as the referred DVB service, except for the partially available 
case where (void) PMT sub tables referring local DVB services MAY be found in the global regionalized TS. 

Descriptors in the PMT important for use in IPDC DVB-SH Systems are: 

data_broadcast_id_descriptor: For each component containing INT sub_table(s), this descriptor with 
data_broadcast_id set to OxOOOB (IP/MAC Notification Info Structure) is located in the ES_info loop. Each 
INT sub_table within the Elementary Stream is announced. 

stream_identifier_descriptor: for each component carrying IP streams, this descriptor is located in the ES_info 
loop. The component_tag announced within the descriptor is unique for each component within the DVB 

service. 

4.5.2.2 Requirements (normative) 

The following requirements apply to all cases. 

• Generic requirements 

DVB-SH Receiver SHALL support usage of multiple PMT sub_tables on a Transport Stream for a single 
IP platform. 

DVB-SH Network SHALL transmit all PMT sub-tables on each Transport Stream of the DVB network. 

The repetition period of all PMT sections is RECOMMENDED to be SH_frame_duration or lower. 

A PMT sub-table SHALL be carried by a unique section of maximum size 1 024 bytes, including header 
and CRC, where the section number field is set to 0. 
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Each PMT sub_table is delivered in an Elementary Stream on the PID announced in the PAT. Different 
PMT sub_tables may be delivered on different Elementary Streams, in which case they are differentiated 
by the PID. However different PMT sub-tables MAY be delivered on the same Elementary Stream, in 
which case sub-tables are differentiated by the program_number. 

The PCR_PID field MAY be set to OxlFFF, indicating that no PCR is associated with the program. 

DVB-SH Receiver MAY ignore PCR even if available. 

• The following descriptor types are important in DVB-SH System and may appear in a PMT sub_table: 

stream_identifier_descriptor; 
data_broadcast_id_descriptor. 

• DVB-SH Receiver MAY ignore all other descriptors, when present. 

• DVB-SH Receiver SHOULD follow changes in PMT sub_table while accessing components of the DVB 
service. Id est while receiving an INT sub_table or an IP stream carried within the components of a DVB 
service, a Receiver SHOULD also filter for newer versions of the PMT sub_table of that DVB service. 

The following requirements apply to A/V services: 

• These requirements apply for components carrying IP stream. 

• For each component carrying IP stream(s), the stream_type SHALL be set to value of 0x90. 

• The ES_info_loop associated with an Elementary Stream carrying IP stream(s) SHALL contain a 
stream_identifier_descriptor announcing the component_tag of the Elementary Stream. This component_tag 
SHALL be unique within the DVB service. The announced component_tag SHALL have the same value as in 
the corresponding data_broadcast_descriptor in the SDT (if any). 

• If a DVB-SH Receiver is receiving an IP stream, the following applies: 

The Receiver SHALL detect changes in an INT sub_table within the same Transport Stream announcing 
the received IP stream by detecting changes in PMT sub_table announcing the Elementary Stream where 
INT sub_table is carried. 

In connection with receiving a burst. Receiver SHALL check for a new version of the corresponding 
PMT sub_table during on-time of the time-sliced Elementary Stream. Receiver MAY ignore filtering of 
the particular PMT sub_table during the off -period of the time-sliced Elementary Stream. 

The following requirements apply to notification services: 

• These requirements apply for components carrying INT sub-tables. 

• In case there is only one IP platform, component(s) carrying INT sub_table(s) SHOULD be announced as the 
first component(s) within the PMT sub_table of the DVB service. In case of several IP platforms, all 
components ) carrying INT sub_table(s) MAY be found in the same PMT sub_table. 

• For each component carrying INT sub_table(s), the stream_type SHOULD be set to value of 0x05. 

• Each INT sub_table within an Elementary Stream SHALL be announced using a data_broadcast_id_descriptor 
in the corresponding PMT sub_table. The descriptor SHALL be located in ES_info_loop associated with the 
component. The descriptor SHALL appear exactly once for each INT sub_table carried within the Elementary 
Stream. In the data_broadcast_id_descriptor, the data_broadcast_id SHALL be set to value of OxOOOB, 
indicating that the descriptor contains IP/MAC Notification Info Structure (see clause 4.9). 

The following requirements apply to cases where the TS is of paTS nature at SH service layer: 

• During global "regionalized TS" transmission of the common SH services, all PMT of the "complete TS" are 
repeated. Those PMT listing local DVB services MUST be void (ES_info_length set to '0'). 
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• During local "regionalized TS" transmission of the local SH services, only those PMT of the "complete TS" 
listing DVB services that are present MUST be present and MUST NOT be void. In case several local SH 
services are present, each PMT MUST be located in the SH service carrying the DVB service signalled by this 
PMT. 

• The PMT sub-tables corresponding to the different DVB local services SHOULD be transmitted on the same 
Elementray Stream with the same PID. Section packing SHALL be used to lower transmission overhead, 
especially when a high number of local services is present. 

• A PMT sub-table section SHALL not span two successive SH services: one PMT sub-table section SHALL 
end before the end of the current SH service. 

The following requirements apply to cases where the TS is of paTS nature at TS layer: 

• During global "regionalized TS" transmission, only the PMT of the common DVB services are transmitted. 
Those PMT listing local DVB services MUST not be present. 

• During local "regionalized TS" transmission, only the PMT of the common and those local DVB services 
actually present are transmitted. Those PMT listing local DVB services not present MUST not be transmitted. 

4.5.3 Conditional Access Table (CAT) 

Same content as [8], clauses 5.4.3 and 4.4.3. 

4.5.4 Transport Stream Description Table (TSDT) 

Same content as [8], clauses 5.4.4 and 4.4.4. 

4.6 SI Tables (normative) 

4.6.1 Bit rates and repetition intervals 



4.6.1.1 



SH modes excluding diversity at SH service level 



In all SH modes excluding diversity at SH service level, the following applies to all SI tables transmitted over the TS 
exiting the IP encapsulator: 

The time between transmitting sequential sections of a sub_table SHOULD NOT exceed 100 ms, and the time 
between the last byte of the preceding section and the first byte of the next section SHALL not be less than 

25 ms. 

The bandwidth used by an Elementary Stream transmitting sections of any sub_table SHOULD NOT exceed 
I Mbps calculated over any period of half a second. 

TS 102 470-1 [8] illustrates the requirements for times between sections of a sub_table. The maximum time of 100 ms 
is between sequential sections of a sub_table. The minimum time of 25 ms is between the last section of a sub_table to 
the first section of the next occurrence of the sub_table. The maximum repetition rate of a table defines the maximum 
time within which all sections of every sub_table of the table shall be transmitted once. 

Note that different sub_tables of a particular table may be transmitted simultaneously. 
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Figure 15: Times between sections of sub_tables (general case) 
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4.6.1 .2 SH modes supporting diversity at SH service level 

In modes supporting diversity at SH service level, these rules at the output of the IP encapsulator are modified as 
follows: 

In the common DVB service, the preceding rules MUST be respected with the corresponding global 
"regionalized TS" bit rate and during the common service duration. 

In the local DVB services, the rules MUST be respected for each service with the corresponding local 
"regionalized TS" bitrate and during the local service duration. 

The stretch factor being defined as the ratio between the local and the global "regionalized TS" bitrates 
(stretch_factor>l), due to the repetition of the common service on the local network: 

The repetition intervals within the common service will be higher and the 25 ms time between two 
succeeding sections of the same sub table must not be lower than stretch_factor*25. 

The bandwidth used by an Elementary Stream transmitting sections of any sub_table calculated over any 
period of half a second will be higher. 
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Figure 16: Times between sections of sub_tables (code diversity case) 
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Therefore the rules are the following in case diversity at SH service level is used: 

The time between transmitting sequential sections of a sub_table SHOULD NOT exceed 100 ms as computed 
with a bit rate equal to the global "regionalized TS" one for the common service and the local "regionalized 
TS" one for the local service. 

In the common service, the time between the last byte of the preceding section and the first byte of the next 
section SHALL not be less than 25 ms multiplied by the stretch_factor and as computed with a bit rate equal to 
the global "regionalized TS" one. 

In the local service, the time between the last byte of the preceding section and the first byte of the next section 
SHALL not be less than 25 ms as computed with a bit rate equal to the local one. 

In the common service, the bandwidth used by an Elementary Stream transmitting sections of any sub_table 
SHOULD NOT exceed 1 Mbps / stretch_factor calculated over any period of half a second with the global bit 
rate. 

In the local service, the bandwidth used by an Elementary Stream transmitting sections of any sub_table 
SHOULD NOT exceed 1 Mbps calculated over any period of half a second and with the local "regionalized 
TS" bit rate. 

4.6.2 Network Information Table (NIT) 
4.6.2.1 NIT_actual 

4.6.2.1.1 Introduction (informative) 

In general clause 4.5.1 of [8] applies unless contradicted by the requirements below. 

4.6.2.1.2 Generalities 

A DVB-SH Network SHALL transmit the NIT_actual on each Transport Stream of the DVB network. The NIT_actual 
SHALL contain exactly one SH_delivery_system_descriptor for each of Transport Streams of the actual delivery 
system and provide valid information about the Transport Stream. 

A cell MAY contain multiple Transport Streams where IP streams are carried over DVB-SH sent on different 
frequencies. When hierarchical modulation is used, there MAY be up to two TS sent in the same frequency AND cell. 

The following descriptors are important in DVB-SH System and SHALL appear in a NIT_actual sub_table: 

network_name_descriptor; 

linkage_descriptor with a linkage type of OxOB or OxOC; 

SH_delivery_system_descriptor; 

cell_list_descriptor; 

cell_frequency_link_descriptor. 

The following descriptor MAY appear in a NIT_actual sub_table: 

• time_slice_fec_identifier_descriptor. 

DVB-SH Receiver MAY ignore other descriptors, when present. 

DVB-SH Receiver MAY assume the content of NIT_actual being static (i.e. not changing) during the time it is attached 
to a DVB network. Therefore a receiver may read the content of NIT_actual only when it attaches to the DVB network. 
A DVB-SH Receiver SHOULD read the content of NIT_actual every time it is attaching a DVB network (either when 
powered on, or when changing from a DVB network to another). The NIT does not depend on the location of the 
receiver and is the same under satellite and terrestrial coverage. 
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Due to the potentially large size of a NIT, it MAY be possible that the NIT exceeds the admissible size of a sub-table. In 
that case, the segmentation rules found in [i.l], clause 4.1.11.2 apply. 

4.6.2.1 .3 Linkage descriptors 

The following applies to each Transport Stream carrying one or more INT sub_tables: 

• The NIT_actual SHALL contain at least one linkage_descriptor with a linkage_type of OxOB or OxOC. 

• If the NIT_actual carries linkage_descriptor(s) with a linkage_type of OxOB, the following applies: 

The descriptor(s) SHALL announce each DVB service carrying INT sub_table(s) within the actual DVB 
network. 

Each of the descriptor(s) SHALL carry exactly one IP/MAC Notification Service Structure announcing 
one or more IP/MAC Notification Services. 

The list of IP/MAC Notification Services announced SHALL be complete. The list is complete if all INT 
sub_tables within the DVB network are referred to by at least one linkage_descriptor with a linkage_type 
of OxOB. 

The following applies to each Transport Stream not carrying any IP flows: 

The Transport Stream SHOULD carry a linkage_descriptor with a linkage_type of OxOC within its NIT_actual, 
announcing at least one NIT_actual within the DVB network containing a linkage_descriptor with a linkage_type of 
OxOB. 

4.6.2.1 .4 Network_name_descriptors 

The following applies to the network_name_descriptor: 

The descriptor SHALL appear exactly once in the first descriptor loop. The descriptor SHOULD contain the name of 
the DVB network (i.e. SHOULD NOT contain an empty string). 

4.6.2.1.5 SH_delivery_system_descriptor, cell_list_descriptor, 
cell_frequency_link_descriptor 

The following applies to the SH_delivery_system_descriptor: 

• The descriptor SHALL appear at most once in each iteration of the transport_stream_loop (i.e. for each 
announced Transport Stream). Traditionally the descriptor is assumed to appear once in each iteration. 
However when several iterations make use of exactly the same descriptor, it can be omitted in replacement of 
the latest previously listed. 

• The descriptor announces the use of the LL service option. If the ll_service_mode is "0000", there is no LL 
service present. If a system does not support the use of LL services it SHALL also set this value to "0000". If 
the value is larger than it states the presence of an LL service in the stream and also gives its puncturing 
pattern (refer to clause 4.10.2.7). 

• There is no frequency given in the SH_delivery_system_descriptor, these are signalled by the 
cell_frequency_link_descriptor. 

The following applies to the cell_list_descriptor: 

• The descriptor SHALL be present in the first descriptor loop. 

• The descriptor MAY appear more than once within the descriptor loop. 

• Descriptor syntax MUST follow rules defined in clause 4.4.4, in particular: 

The cell and subcell list SHALL be complete. 

Cell_id range depends on cell type (satellite, terrestrial). 
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The following applies to the cell_frequency_link_descriptor: 

• This descriptor SHALL appear in the transport_stream_loop to list all the frequencies where the Transport 
Stream is available within the DVB network. 

• Descriptor syntax SHALL follow rules defined in clause 4.4.5, in particular: 

The list of announced frequencies SHALL be complete. 

Cell list order depends on cell type (satellite, terrestrial). 

The way SH_delivery_system_descriptor, cell_list_descriptor and cell_frequency_link_descriptor and combined is the 
following: 

• Inside the main loop, the cell_list_descriptor describes all cells present in the network, their cell_id and 
latitude/longitude extension MUST follow the specific syntax given in clause 4.4.4. 

• For each TS in the TS loop, one SH_delivery_system_descriptor is given that follows the syntax of 
clause 4.4. 1 and gives as many modulation loop as needed. 

• For each TS in the TS loop, one (logical-wise since actually several descriptors MAY be used depending on 
the size of the list and the topology of the groups) a cell_frequency_link_descriptor follows that specifies on 
which cells and what frequencies the TS is being repeated. The cells are grouped in two categories depending 
on their cell_id, the satellite and the terrestrial. 

• Cells belonging to different categories (satellite and terrestrial) MAY be found in the same descriptor provided 
that the order (satellite first, terrestrial second) is respected, but this is not mandatory. A different descriptor 
MAY be used to list the terrestrial cells. 

• Inside each category, the following rules apply individually: 

If there are as many cell entries in the cell_frequency_link_descriptor as there are modulation entries in 
the SH_delivery_system_descriptor, then the modulation entries are one to one allocated to the different 
cells: first modulation entry to first cell, second modulation entry to second cell, etc. 

If there are more than one entry in the cell_frequency_link_descriptor but only one modulation entry in 
the SH_delivery_system_descriptor, then this unique modulation entry MUST be allocated to all cells 
listed in the cell_frequency_link_descriptor. 

EXAMPLE: We assume in Table 4 a SH-B system where a unique TS is being distributed over a unique 
satellite cell and 10 local cells. 
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Table 4: Example of SH-B NIT (1 TS, 1 satellite cell, 10 terrestrial cells) 



Syntax 


N of bits 


elements 


Multi 


network_information_section(){ 








tablejd 


8 




8 


section_syntax_indicator 


1 




1 


reserved_for_future_use 


1 




1 


reserved 


2 




2 


sectionjength 


12 




12 


networkjd 


16 




16 


reserved 


2 




2 


version_number 


5 




5 


current_next_indicator 


1 




1 


section_number 


8 




8 


last_section_number 


8 




8 


reserved_for_future_use 


4 




4 


network_descriptor_length 


12 




12 


network_name_descriptor 


96 




96 


cell_list_descriptor 


816 




816 


linkage_descriptor 


72 




72 


reserved_for_future_use 


4 




4 


transport_stream_loop_length 


12 




12 


transport_stream_id 


16 




16 


original_network_id 


16 




16 


reserved_for_future_use 


4 




4 


transport_descriptors_length 


12 




12 


SH_system_d el i very_d escr i pto r 


96 




96 


cell_frequency_link_descriptor 


552 




552 


CFC32 

} 


32 


1 


32 



satellite TS loop 



cell_list_descriptor 






descriptorjag 




8 


descriptorjength 




8 


All cells 




792 


cell id 


16 




cell latitude 


16 




celljongitude 


16 




cell extent of latitude 


12 




cell_extent_of_longitude 


12 




subcelljnfojoopjength 




8 
816 



1 sat + 10 ter cells 



unitary size 
72 bytes 



cell_frequency_link_descriptor 
descriptorjag 
descriptorjength 
All cells 




8 

8 

528 


cell id 


16 




frequency 
subcelljnfojoopjength 


32 


8 
552 



1 sat + 10 ter cells 
unitary size 
48 bytes 
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NOTE 1: It can be seen that the number of listed satellite and terrestrial cells in the cell_list_descriptor is 1 and 10 
respectively. In the TS loop, there is only one TS being listed, the satellite one. The 
SH_delivery_system_descriptor has 2 entries, 1 for TDM and 1 for OFDMA, whereas the 
cell_frequency_link_descriptor lists 1 1 entries, the first being the satellite cell (cell_id < 256) and the 
others being terrestrial cells (cell_id > 255). Therefore the unique satellite cell is related to the unique 
satellite TDM modulation entry whereas the terrestrial cells are all related to the also unique OFDMA 
modulation entry. 

If there are larger entries in the cell_frequency_link_descriptor than in the 
SH_delivery_system_descriptor and there are several modulation entries, then each modulation 
entry is allocated to a distinct group of cells according to the following rules: 

Each modulation entry corresponds to a group of cells. Therefore there are as many groups of 
cells as there are modulation entries. 

Cells (and their corresponding frequencies) belonging to a group of cell (and for which a 
specific modulation entry apply) are listed by a cell_frequency_link_descriptor or a set of 
consecutive cell_frequency_link_descriptors when the size of one descriptor reaches the 
capacity of an individual descriptor and/or the capacity of an individual NIT sub-table. In the 
latter cases splitting rules described in [i.l], clause 4.1.11.2 apply. 

When the list of {cells; frequencies} belonging to this group is complete and a new group has 
to be listed, a void cell_frequency_link_descriptor is inserted between the two groups to 
delineate the separation between two consecutive groups and avoid ambiguity about which 
modulation entry is used. 

EXAMPLE: We assume in Table 5 a SH-A system where a unique TS is being distributed over a unique 

satellite cell and two groups made of 10 cells each. The two groups have different modulation 
parameters differing only by the used FFT. 



£75/ 



51 



ETSI TS 102 470-2 VI .2.1 (2011-09) 



Table 5: Example of SH-B with two groups of terrestrial cells having different FFT 



Syntax 


Nof bits 


eiements 


Muiti 


network information section()( 








tabie id 


6 




8 


section syntax indicator 


1 




1 


reserved for future use 


1 




1 


reserved 


2 




2 


section iength 


12 




12 


networl< id 


16 




16 


reserved 


2 




2 


version number 


5 




5 


current next indicator 


1 




1 


section number 


6 




6 


iast section number 


6 




6 


reserved for future use 


4 




4 


networl< descriptor iength 


12 




12 


networl< name descriptor 


96 




96 


ceii iist descriptor part 1 


16 







ceii iist descriptor part 2 


896 




896 


iinl<age descriptor 


72 




144 


reserved for future use 


4 




4 


transport stream ioop iength 


12 




12 


transport stream id 


16 




16 


originai networl< id 


16 




16 


reserved for future use 


4 




4 


transport descriptors iength 


12 




12 


SH system deiivery descriptor 


120 




120-^ 


ceii frequency iinl< descriptor 


680 




A 680 


CRC32 
} 


32 




/'' 



Syntax 


Nof bits 


eiement 


SH deiivery system descriptor(){ 






descriptor tag 


6 




descriptor iength 


8 




descriptor tag_extension 


6 




diversity mode 


4 




reserved 


4 




tdm moduiation descriptor 


24 


1*^ 


interieaver descriptor compiete 


32 





ofdm moduiation descriptor 


24 


2 '^ 


inlerleaver descriptor partial 
} 


8 


2 



1 TDM modulation 



■ 2 OFDM modulation (FFT 1 a FFT 2) 



72+2*296+16=680' 



1X: 
2X: 

1X: 






_ TDM links 

. . OFDM links 

, - Transition between 2 OFDM groups 


c ei i_freq u en cy_i i n l<_desc ri ptor_sate i i ite 

descriptorjag 

descriptorjength 

Aii_ceiis 

ceiijd 16 

frequency 32 

subcellJnfojQopJength 8 


8 
8 
56 


72 






c e ]]_fr e q u e n cyj 1 n k_d e scri ptor_terre stri ai 

descriptorjag 

descriptorjength 

Aii_ceiis 

ceiijd 16 

frequency 32 

subceiijnfojoopjength 8 


8 
280 


296 






c ei i_frequ e n cy J i n l<_d esc ri ptor_terrestri a i 

descriptorjag 

descriptor iength 

Aii_ceiis 

ceiijd 16 

frequency 32 

subceiijnfojoopjength 8 


8 
8 


16 







NOTE 2: It can be seen that the number of listed satelHte and terrestrial cells in the cellJist_descriptor is 1 and 10 
respectively. In the TS loop, there is only one TS being listed, the satellite one. The 
SH_delivery_system_descriptor has 3 entries, 1 for TDM and 2 for OFDMA (one with FFT 1, the other 
with FFT 2) whereas the cell_frequencyJink_descriptor lists 1 1 entries in 3 separate descriptors: the first 
descriptor lists the unique satellite cell and frequency (cell_id < 256), the second lists the 5 cells and 
frequencies using the first OFDMA modulation and the last lists the 5 cells and frequencies related to the 
second OFDMA modulation. 

NOTE 3: It would have been possible to list the satellite and the first 5 cells of the first group in the same 

cell_frequency_link_descriptor since their cell_id can identify them unambiguously. For clarity purpose 
we have separated them in 2 descriptors in the example given. 

4.6.2.1 .6 time_slice_fec_identifier_descriptor 

The following applies to the time_slice_fec_identifier_descriptor: 

• When located in the first descriptor loop, the descriptor applies to all elementary streams with stream_type 
0x90 within all transport streams announced within the sub-table. 

• When located in the second descriptor loop, the descriptor applies to all elementary streams with stream_type 
0x90 within the specific transport stream. This descriptor overwrites any descriptors in the first descriptor 
loop. 
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4.6.2.2 NIT_other 

4.6.2.2.1 Specific requirements 

A DVB-SH Network MAY transmit NIT_other on one or more Transport Streams of the DVB network. NIT_other has 
to be valid and only announce an existing network. In case other network is delivered using SH modulation, NIT_other 
SHALL contain exactly one SH_delivery_system_descriptor for each of the Transport Streams of the actual delivery 
system and provide valid information about the Transport Stream. Otherwise, NIT_other follows specification of [8], 
clause 5.5. L2 

4.6.2.2.2 Generic requirements 

Other requirements applicable for NIT_actual are also application for NIT_other. 

4.6.3 Bouquet Association Table (BAT) 

Same as [8], clauses 5.5.2 and 4.5.2. 

4.6.4 Service Description Table (SDT) 

4.6.4.1 Introduction 

In DVB-SH networks with paTS, different types of SDT tables can be used, contrarily to DVB-H networks where only 
SDT_actual are used: 

SDT_actual (table_id = 0x42) describes the services present in actual TS. 

SDT_other (table_id = 0x46) describes the services present in other TS, be they in the current or other 
networks. 

The two types of table are defined in [1], clause 5.2.3. 

4.6.4.2 SDT_actual 

A DVB-SH Network SHALL transmit SDT_actual sub_table (tablejd 0x42) for the actual Transport Stream. All 
transmitted sections of the SDT_actual for the actual multiplex SHALL be transmitted at least every 2 s. 

The services_loop of the SDT_actual sub-table SHALL contain information about all DVB services composing the 
Transport Stream (id-est before filtering when this is a paTS). Each DVB service SHOULD NOT be announced more 
than once within an SDT_actual sub_table. 

In a DVB-SH System, the following descriptor types SHALL appear in the SDT_actual of a Transport Stream where 
one or more MPE section streams are available: 

service_descriptor; 

data_broadcast_descriptor. 

In a DVB-SH System, the following descriptor types MAY appear in the SDT-actual of a Transport Stream where one 
or more MPE section streams are available: 

service_availability_descriptor. 

DVB-SH Receiver MAY ignore other descriptors, when present. 

The following applies to the SDT_actual when announcing a DVB service carrying INT sub_table or IP streams: 

• The EIT_schedule_flag SHOULD be set to value of 0x00, indicating that the EIT schedule information for the 
DVB service is not present in the Transport Stream. DVB-SH Receiver MAY ignore schedule information if 
present. 

• DVB-SH Receiver MAY ignore present/following information if present. 
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• The running_status SHOULD be set to value of 0x04, indicating that the DVB service is currently running. 

• The following applies to the service_descriptor: 

The descriptor SHALL be present. 

DVB-SH Receiver SHALL NOT assume any particular value for the service_type. 

The service_provider_name MAY contain the service provider name. DVB-SH Receiver MAY ignore 
service provider name. 

The service_name MAY contain the DVB service name. DVB-SH Receiver MAY ignore service name. 

• The following applies to the data_broadcast_descriptor: 

The descriptor SHALL be present for each component carrying one or more MPE section streams within 
the DVB service. 

It MAY occur more than once. DVB-SH Receiver MAY ignore them all but one, for which the following 
applies: 

The data_broadcast_id field SHALL be set to value 0x0005. 

The component_tag field SHALL be set to the value of the component announced within the PMT 
sub_table of the DVB service. 

The descriptor SHALL contain Multiprotocol Encapsulation Info Structure. For the structure, the 
following applies: 

MAC_address_range SHALL be set to value of 0x01, indicating that only MAC_address_6 
in the header of MPE sections carried within the referred component contains valid 
MAC-address information; 

MAC_IP_mapping_flag SHOULD be set to T, indicating that it uses the IP to MAC 
mapping as described in RFC 1112 [3] for IPv4 multicast addresses, and RFC 2464 [4] for 
IPv6 multicast addresses; 

alignment_indicator SHALL be set to '0', indicating that alignment of 8 bits is used; 

max_sections_per_datagram SHALL be set to value of 0x01, indicating that each IP 
datagram is carried in exactly one MPE section. 

DVB-SH Receiver MAY ignore the text description of the data component, if present. 

• The following applies to the service_availability_descriptor: 

The inclusion as well as the generation of this descriptor SHALL follow clause 5.3.3 of the present 
document. 

Note that a DVB-SH Receiver does not use MAC address for filtering MPE section streams. 

A DVB-SH Receiver SHALL NOT ignore SDT_actual, when it describes a paTS as signalled by 

SH_delivery_system_descriptor, as it may signal some restrictions on the service availability of the described Transport 
Stream. 

4.6.4.3 SDT_other 

A DVB-SH Network SHALL transmit SDT_other sub_table (table_id 0x46) for each non-actual Transport Stream 
fulfilling the three following conditions: 

The Transport Stream is a paTS as announced by SH_delivery_system_descriptor diversity _mode. 

The Transport Stream is a neighbouring Transport Stream, i.e. transmitted in geographically co-located, 
adjacent or intersecting cells, whether belonging to the actual and/or other network(s). 

The Transport Stream is actually filtered in one of the neighbouring cells. 
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All transmitted sections of the SDT_other for the actual multiplex SHALL be transmitted at least every 10 s. 

Remaining requirements are similar to SDT_actual and recalled for memory. 

The services_loop of the SDT_other sub-table SHALL contain information about all DVB services composing the 
Transport Stream (id-est before filtering when this is a paTS). Each DVB service SHOULD NOT be announced more 
than once within an SDT_other sub_table. 

In a DVB-SH System, the following descriptor types SHALL appear in the SDT_other of a Transport Stream where one 
or more MPE section streams are available: 

service_descriptor; 

data_broadcast_descriptor. 

In a DVB-SH System, the following descriptor types MAY appear in the SDT_other of a Transport Stream where one 
or more MPE section streams are available: 

service_availability_descriptor. 

DVB-SH Receiver MAY ignore other descriptors, when present. 

The following applies to the SDT_other when announcing a DVB service carrying INT sub_table or IP streams: 

• The EIT_schedule_flag SHOULD be set to value of 0x00, indicating that the EIT schedule information for the 
DVB service is not present in the Transport Stream. DVB-SH Receiver MAY ignore schedule information if 
present. 

• DVB-SH Receiver MAY ignore present/following information if present. 

• The running_status SHOULD be set to value of 0x04, indicating that the DVB service is currently running. 

• The following applies to the service_descriptor: 

The descriptor SHALL be present. 

DVB-SH Receiver SHALL NOT assume any particular value for the service_type. 

The service_provider_name MAY contain the service provider name. DVB-SH Receiver MAY ignore 
service provider name. 

The service_name MAY contain the DVB service name. DVB-SH Receiver MAY ignore service name. 

• The following applies to the data_broadcast_descriptor: 

The descriptor SHALL be present for each component carrying one or more MPE section streams within 
the DVB service. 

It MAY occur more than once. DVB-SH Receiver MAY ignore them all but one, for which the following 
applies: 

The data_broadcast_id field SHALL be set to value 0x0005. 

The component_tag field SHALL be set to the value of the component announced within the PMT 
sub table of the DVB service of the other TS. 
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The descriptor SHALL contain Multiprotocol Encapsulation Info Structure. For the structure, the 
following applies: 

MAC_address_range SHALL be set to value of 0x01, indicating that only MAC_address_6 
in the header of MPE sections carried within the referred component contains valid 
MAC-address information; 

MAC_IP_mapping_flag SHOULD be set to T, indicating that it uses the IP to MAC 
mapping as described in RFC 1112 [3] for IPv4 multicast addresses, and RFC 2464 [4] for 
IPv6 multicast addresses; 

alignment_indicator SHALL be set to '0', indicating that alignment of 8 bits is used; 

max_sections_per_datagram SHALL be set to value of 0x01, indicating that each IP 
datagram is carried in exactly one MPE section. 

DVB-SH Receiver MAY ignore the text description of the data component, if present. 

The following applies to the service_availability_descriptor: 

The inclusion as well as the generation of this descriptor SHALL follow clause 5.3.3 of the present document. 

Note that a DVB-SH Receiver does not use MAC address for filtering MPE section streams. 

A DVB-SH Receiver SHALL NOT ignore SDT_other, when it describes a paTS as signalled by 

SH_delivery_system_descriptor, as it may signal some restrictions on the service availability of the described Transport 
Stream. 

4.6.4.4 Determining service availability 

4.6.4.4.1 Service availability of the actual TS on the current cell 

This clause specifies how an IPDC DVB-SH Receiver can determine the service availability of the actual Transport 
Stream on the current cell. 

In this procedure, the following prerequisites are known to the IPDC DVB-SH Receiver: 

Identity of the actual Transport Stream (original_network_id, transport_stream_id). 

If one service only is of interest, identity of the service (service_id). 

Identity of the current cell (cell_id). 

The IPDC DVB-SH Receiver SHOULD conclude to the availability of all the services of the actual Transport Stream 
on the current cell: 

if the delivery_system_descriptor given for the Transport Stream implicitly or explicitly declares to not 
support or apply service filtering; or else 

if the SDT_actual sub_table is (unexpectedly) not found. 

Otherwise, the IPDC DVB-SH Receiver SHOULD determine the availability of [one specific service I each service] of 
the actual transport Stream as follows: for [the service entry I for each service entry] in the servicesjoop of SDT_actual 
sub_table, the service is available on current cell: 

if the service_availability_descriptor is absent; or else 

if the availability_flag is unset and actual cell_id is not listed in the descriptor; or else 

if the availability_flag is set and actual cell_id is listed in the descriptor; 

otherwise the service is not available on the current cell. 
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4.6.4.4.2 Service availability of a TS on the cells of a given network 

This clause specifies how an IPDC DVB-SH Receiver can determine the service availability of a Transport Stream in a 
given network. More specifically the purpose of this procedure is to determine, within the cells listed by the 
cell_frequency_link_descriptor given for the Transport Stream in this network, on which cell(s) each service is actually 
available. 

In this procedure, the following prerequisites are known to the IPDC DVB-SH Receiver: 

Identity of the Transport Stream (original_network_id, transport_stream_id). 

If one service only is of interest, identity of the service (service_id). 

Identity of the network (network_id). 

The IPDC DVB-SH Receiver performs the following initialization steps (should one of these steps fails, the procedure 
is aborted): 

If not already done, retrieve the NIT sub_table identified by network_id. 

If not already done, check the presence of the Transport Stream in the TS loop of the NIT sub_table. 

Retrieve the cell_frequency_link_descriptor as well as the delivery_system_descriptor given for the Transport 
Stream in the TS loop iteration. 

The IPDC DVB-SH Receiver SHOULD conclude to the availability of all the services of the Transport Stream on all 
the cells listed by the cell_frequency_link_descriptor: 

if the delivery_system_descriptor implicitly or explicitly declares to not support or apply service filtering, or 
else; 

if the SDT (actual or other) sub_table associated to this Transport Stream is not found. 

Otherwise, the IPDC DVB-SH Receiver SHOULD determine the availability of [one specific service I each service] of 
the actual transport Stream as follows: for [the service entry I for each service entry] in the servicesjoop of SDT 
sub_table : 

if the service_availability_descriptor is absent, the service is available on all the cells listed by the 
cell_frequency_link_descriptor, or else; 

if the availability_flag is unset, the service is only available on the cells of the cell_frequency_link_descriptor 
which are not listed in the service_availability_descriptor, or else; 

if the availability_flag is set, the service is only available on the cells listed by the 
cell_frequency_link_descriptor which are besides listed in the service_availability_descriptor. 

4.6.5 Event Information Table (EIT) 

Same as clauses 5.5.4 and 4.5.4 in [8]. 

4.6.6 Running Status Table (RST) 

Same as clauses 5.5.5 and 4.5.5 in [8]. 

4.6.7 Time and Date Table (TDT) 

Same as clauses 5.5.6 and 4.5.6 in [8]. 

4.6.8 Time Offset Table (TOT) 

Same as clauses 5.5.7 and 4.5.7 in [8]. 
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4.6.9 Stuffing Table (ST) 

Same as clauses 5.5.8 and 4.5.8 in [8]. 

4.6.10 IP/MAC Notification Table (INT) 

This clause gives precisions on the way INT MUST be used in a DVB-SH context. It is divided into two parts: the first 
is valid for all SH configurations whereas the second specific to cases when the TS is partially available. 

4.6.10.1 Common specifications 

4.6.10.1.0 Introduction 

This clause is applicable to all SH configurations. 

4.6.10.1.1 Generalities 

An IP platform MAY have IP streams on multiple Transport Streams within a DVB network. An IP platform MAY 
have IP streams on multiple DVB networks. 

Two Transport Streams carrying IP streams of a particular IP platform MAY carry the same, partially different, or 
entirely different set of IP flows of the IP platform. 

Two IP flows carried on a single Elementary Stream on a particular Transport Stream MAY be carried on different 
Elementary Streams on another Transport Streams as well. 

If one or more IP streams of an IP platform are carried within a Transport Stream, the Transport Stream SHALL carry 
the INT sub_table describing the IP platform. 

An IP stream MAY be announced on INT sub_tables of two or more IP platforms (i.e. one IP stream MAY belong to 
multiple IP platforms). 

The INT sub_table of a particular IP platform SHALL NOT be carried in multiple Elementary Streams (i.e. only one 
copy allowed) on a particular Transport Stream. 

DVB-SH network MAY use IPv4 and/or IPv6. Within one IP platform, and therefore INT, only one IP version 
SHOULD be used. 

The INT is referenced by a data_broadcast_id_descriptor with a data broadcast id of OxOOOB, in the ES_info loop of the 
PMT (see clause 4.9 for more information on ways to signal the INT). 

An INT table may consist of one or more INT sub_tables. INT sub_tables are differentiated by platform_id and 
action_type: 

The platform_id is used to identify the IP platform. Within the actual transport stream, a DVB-SH Network 
SHALL transmit one INT sub_table for each IP platform delivering IP streams within the Transport Stream. It 
is generally recommended to use one IP platform per service provider. 

The action_type indicates the action to be performed. Currently the only action type supported is 0x01, which 
means that location of IP streams in DVB networks is announced. The processing_order field of an INT 
sub_table with action_type 0x01 SHALL be set to value of OxFF or 0x00, indicating that no ordering is 
implied. 

All transmitted sections of the INT SHALL be transmitted at least once in every 30 s. 

The INT is structured in two loops inside which different descriptors are used: 

the platform_descriptor_loop; 

the target and operational descriptor loops. 
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INT sub_table SHALL announce each IP stream of the IP platform available on the actual Transport Stream 
(i.e. target-loop SHALL contain a descriptor announcing the IP address of the corresponding IP flow, and the 
corresponding operational-loop SHALL contain a descriptor announcing the location of the IP stream within the actual 
Transport Stream). 

INT sub_table SHOULD announce each IP stream of the IP platform available on the neighbouring Transport Streams. 
Neighbouring Transport Streams are Transport Streams, which are transmitted in geographically co-located, adjacent or 
intersecting cells. In the specific case of a satellite cell (called a beam, cell_id < 255) the cell is neighbour of all 
terrestrial cells within the coverage of the satellite cell. Although the number of IP streams MAY be quite large, in 
particular if there are local TS transmitted in the terrestrial cells, a different platform_id for signalling IP streams 
available only on the local TS SHALL be avoided. 

4.6.10.1.2 Platformdescriptorjoop 

The following descriptors MAY appear in platform_descriptor_loop: 

IP/MAC_platform_name_descriptor: Platformjoop MAY contain this descriptor, containing the name of the 
IP platform in one or more languages. The descriptor MAY occur more than once. Each occurrence of the 
platform_name SHOULD be identical with the platform_name announced using the same language code in 
NIT containing IP/MAC Notification Service Structure. 

time_slice_fec_identifier_descriptor: If this descriptor is present in platformjoop, it indicates that all 
Elementary Streams referred within this INT sub_table are time-sliced with parameters announced in this 
descriptor. 

DVB-SH Receiver MAY ignore all other descriptors in platform-loop. 

4.6.1 0.1 .3 Target_descriptor_loop 

Following descriptors MAY appear in target-loop: 

target_IP_address_descriptor; 

target_IP_slash_descriptor; 

target_IP_source_slash_descriptor; 

target_IPv6_address_descriptor; 

target_IPv6_slash_descriptor; 

target_IPv6_source_slash_descriptor. 

Each iteration of 2"'^ loop of INT table SHALL contain at least one of the above listed target-descriptors in target-loop. 

Descriptor_length field of any descriptor in this loop SHALL NOT be set to "0" (i.e. the descriptor SHALL signal at 
least one IP flow). 

An IP flow SHALL NOT be announced in more than one iteration of 2"'^ loop of INT table. 

IP streams carried within an Elementary Stream SHALL use the same version of IP protocol. I.e. mixing IPv4 and IPv6 
datagrams within a single Elementary Stream is not allowed. 

Following applies to each target_IP_address_descriptor within the 2"'^ loop of INT table: 

The use of target_IP_slash_descriptor or target_IP_source_slash_descriptor instead is RECOMMENDED. 

Note that this descriptor can contain maximum of 62 IPv4_addr fields. 

IPv4_addr_mask field indicates the bits significant in each IP address announced in the following IPv4_addr 
fields within the descriptor. 

This descriptor refers to every IP flow with any source address and any of the announced destination address. 
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Following applies to each target_IP_slash_descriptor within the 2"'^ loop of INT table: 
Note that this descriptor can contain maximum of 5 1 IPv4_addr fields. 

IPv4_slash_mask indicates the number of significant bits in the corresponding IPv4_addr, starting from the 

msb. 

This descriptor refers to every IP flow with any source address and any of the announced destination address. 

Following applies to each target_IP_source_slash_descriptor within the 2"'^ loop of INT table: 

Note that this descriptor can contain maximum of 25 IPv4_addr fields. 

IPv4_source_slash_mask indicates the number of significant bits in the corresponding IPv4_source_addr, 
starting from the msb. 

IPv4_dest_slash_mask indicates the number of significant bits in the corresponding IPv4_dest_addr, starting 
from the msb. 

This descriptor refers to every IP flow with any of the announced source address and any of the announced 
destination address. 

Following applies to each target_IPv6_address_descriptor within the 2"'^ loop of INT table: 

The use of target_IPv6_slash_descriptor or target_IPv6_source_slash_descriptor instead is 
RECOMMENDED. 

Note that this descriptor can contain maximum of 14 IPv6_addr fields. 

IPv6_addr_mask field indicates the bits significant in each IPv6 address announced in the following IPv6_addr 
fields within the descriptor. IPv6_addr_mask value ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffOO would indicate that the 8 
Isb of the IPv6_addr value are to be ignored. 

This descriptor refers to every IP flow with any source address and any of the announced destination address. 

Following applies to each target_IPv6_slash_descriptor within the 2"'^ loop of INT table: 

Note that this descriptor can contain maximum of 15 IPv6_addr fields. 

IPv6_slash_mask indicates the number of significant bits in the corresponding IPv6_addr, starting from the 
msb. IPv6_slash_mask_value 120 would indicate that the 8 Isb of the IPv6_addr value are to be ignored. 

This descriptor refers to every IP flow with any source address and any of the announced destination address. 

Following applies to each target_IPv6_source_slash_descriptor within the 2"'^ loop of INT table: 

Note that this descriptor can contain maximum of seven (7) IPv6_addr fields. 

IPv6_source_slash_mask indicates the number of significant bits in the corresponding IPv6_source_addr, 
starting from the msb. 

IPv6_dest_slash_mask indicates the number of significant bits in the corresponding IPv6_dest_addr, starting 
from the msb. 

This descriptor refers to every IP flow with any of the announced source address and any of the announced 
destination address. 

If the IP/MAC_stream_location_descriptors associated with the first descriptor announce different locations 
than the IP/MAC_stream_location_descriptors associated with the second descriptor (i.e. located in different 
iteration of 2"'^ loop of INT table), DVB-SH Receiver would need to know which of the locations to use. For 
such cases, following applies: 

If within an INT sub_table an IP flow is announced multiple times using different masks. Receiver 
SHALL use the one with more precise mask (i.e. the mask with more bits set). If several announcements 
are available it is to the implementation to decide which one to use, not to a DVB standard to specify 
this. 
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4.6.1 0.1 .4 Operational_descriptor_loop 



NOTE: This clause is identical to clause 5.5.9 of [8] dealing with operational_descriptor_loop and recalled for 
consistency. 

Following descriptors MAY appear in operational-loop: 

IP/MAC_stream_location_descriptor: Each iteration of 2"'^ loop of INT table SHALL contain at least one 
IP/MAC_stream_location_descriptor in operational-loop, providing the location of IP streams. Given location 
SHALL NOT occur more than once within each iteration of 2"'* loop of INT table. 

time_slice_fec_identifier_descriptor: If this descriptor is present in targetjoop, it indicates that all Elementary 
Streams referred within this loop after this descriptor are time-sliced with parameters announced in this 
descriptor. Descriptor applies from the next IP/MAC_stream_location_descriptor (if any) to the end of the 
current iteration of the loop or to the next time_slice_fec_identifier_descriptor, whichever comes first. 

The IP/MAC_stream_location_descriptor SHOULD have different content within each iteration of 2"'^ loop of INT 
table (i.e. SHOULD announce different location). 

DVB-SH Receiver MAY ignore all other descriptors in operational-loop. 

4.6.1 0.2 Specificities in the case of a partially available TS 

4.6.1 0.2.1 Unicity and availability of the INT 

Each sub-table SHALL be part of the common services in case the TS is partially available so that the complete INT is 
available anywhere in the DVB-SH network. There MAY be a number of IP streams that are not available on the 
common service but only on the local service. Therefore the number of IP streams to be announced in the INT sent in 
the common service MAY be quite large. However due to the 30 seconds repetition interval, the bit rate increase is 
expected to remain limited. 

4.6.1 0.2.2 Multiplicity of IP/MAC_stream_location_descriptors within operationaljoop 

With a partially available TS, it MAY be possible that multiple lP/MACstream_location_descriptor entries exist for 
same target_IP_descriptor, whereby the same IP flow MAY be instantiated by different IP streams found in different 
DVB services. In such case, appearance order of the different IP/MAC_stream_location_descriptors within the 
operationaljoop is of importance and MUST follow the rules : 

if the IP flow is present in a common DVB service, the position of the corresponding 
IP/MAC_stream_location_descriptor SHALL be first; 

if the IP flow is present on several local DVB services. 

The procedure for the receiver to choose the correct IP stream and corresponding DVB service is the following: 

1) The terminal should: 

scan the INT table and the operationaljoop; 

select an IP address ; 

find a matching {target_descriptorJoop(); operational_descriptor Joop() } in the loop following the 
platform_descriptorJoop; 

in the operational_descriptor JoopO more than one IP/MACstreamJocation_descriptor will be found for 
the actual TS; 

the first IP/MACstreamJocation_descriptor of the list should be the one associated with the satellite 
DVB service, other being associated to the local DVB services. 
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2) According to this order, a procedure can be followed as described under: 

Step 1 : list all services that contain the target IP address; 

Step 2: check availability of the service in the SDT table, the latter being cached in the memory; 

Step 3: if only one service is available, use its service_id to trigger the IP flow; 

Step 4: if two services are available, use the service_id that is not in the first position of the list to trigger 
the IP flow. 

4.7 Transmission Parameters Signalling (TPS) 

The Transmission Parameters Signalling (TPS) bits are used to signal parameters related to the OFDMA transmission 
scheme, i.e. to channel coding, modulation and interleaver. They are specified in [6], clause 5.7.4.3. 

The Signalling Field is used to signal parameters related to the TDM transmission scheme, id est interleaver and 
channel coding (the modulation is supposed to have been resolved beforehand). The signalling field is specified in [6], 
clause 5.5.2.2. 

4.8 Update Notification Table (normative) 

Same as clauses 5.7 and 4.10 in [8]. 

4.9 Announcing INT (normative) 

This clause summarizes how the INT SHALL be announced. The description starts from the ES that carries the INT and 
follows signalling backwards. 

4.9.1 IP/MAC Notification Service 

An elementary stream that carries an INT is called IP/MAC Notification service. This Elementary Stream is then called 
a IP/MAC Notification Service. An IP/MAC Notification Service MAY carry multiple INT sub_tables. An IP/MAC 
Notification Service SHOULD NOT carry any other data but INT sub_tables. DVB-SH Receiver MAY ignore any 
other data on an Elementary Stream carrying one or more INT sub_tables. 

The notification service MUST be announced in the PMT describing the elementary stream where the INT is carried. 
The IP/MAC Notification Info Structure announces each INT sub_table carried within the announced component (see 
clause 4.9.2 for more details). 

The DVB service described by this PMT is itself announced by an IP/MAC Notification Service Structure. The latter is 
located within a linkage_descriptor that MAY be found in the NIT_actual of each Transport Stream containing one or 
more IP/MAC Notification Services (see clause 4.9.3 for more details), or in BAT carried on at least one of the 
Transport Streams of the network (see clause 4.9.4 for more details). 

4.9.2 IP/MAC Notification Info structure 

As defined in clause 8.3.1 of [2], the structure is located in the ES_info loop of the PMT, precisely in the selector field 
of data_broadcast_id_descriptor, with the data_broadcast_id field set to OxOOOB. There is exactly one structure per 
data_broadcast_id_descriptor but there MAY be several data_broadcast_id_descriptors within the ES_loop. 

Following applies to each IP/MAC Notification Info Structure found in the PMT: 

At least one INT sub_table SHALL be announced. 

More than one INT sub_tables SHOULD NOT be announced. 

If more than one INT sub_tables are announced within a single structure, each SHALL have a different 
platform_id. 
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If more than one platform_id are present, the list of platform_ids shall be complete. 

For each announced platform_id, action_type 0x01 (location of IP/MAC streams in DVB networks) SHOULD 
be announced exactly once. 

INT_versioning_flag fields SHALL be set to '1', indicating that the INT_version field reflects the changes of 
the announced INT sub_table. 

NOTE: If INT_versioning_flag is set to 1, a Receiver needs to filter only the PMT sub_table to detect changes in 
PMT and INT sub_tables. If the flag is set to 0, the Receiver needs to filter both PMT and INT sub_table, 
therefore requiring one extra filter. 

4.9.3 IP/MAC Notification NIT 

As defined in [1], the IP/MAC Notification Service Structure is carried within exactly one linkage_descriptor, located in 
the first descriptor loop of a NIT. There is exactly one structure per linkage_descriptor but there MAY be several 
linkage_descriptors in the NIT main loop. 

The following applies to each NIT containing IP/MAC Notification Service Structure: 

• Each notification service within the DVB-SH network is announced in the NIT. 

• If there are several IP platforms and therefore several INT sub_tables, these are announced in the same 
IP/MAC Notification Service Structure. 

• In that case, the list of announced IP platforms SHALL be complete, so that each INT sub_table within the 
entire DVB network is referred to by at least one linkage_descriptor containing an IP/MAC Notification 
Service Structure. 

• A platform_name SHALL be given for each announced IP platform. The platform_name MAY be announced 
just once within each NIT containing IP/MAC Notification Service Structures. 

To get the names of each available IP platform within a DVB network, a DVB-SH Receiver would read the NIT 
containing linkage_descriptors with linkage_type OxOB. Within such NIT, names of each available IP platform are 
announced. 

4.9.4 IP/MAC Notification BAT 

If an IP/MAC Notification BAT is used, the following applies: 

The BAT sub_table should be announced within the NIT sub_tables describing the actual delivery system. 

To announce a BAT sub_table, a NIT carries a linkage_descriptor with the linkage_type set to OxOC. 

As defined in [1], the IP/MAC Notification Service Structure is carried within exactly one linkage_descriptor, located in 
the first descriptor loop of a specifically identified BAT sub_table. There is exactly one structure per linkage_descriptor 
but there MAY be several linkage_descriptors in the BAT main loop. 

Each IP/MAC Notification BAT announces each IP/MAC Notification Service within the DVB network. For each such 
DVB service, each IP platform for which INT sub_tables are carried in components of the service, is announced. 

The following applies to each BAT containing IP/MAC Notification Service Structure: 

Each IP/MAC Notification Service within the DVB network is announced in the BAT. 

If there are several IP platforms and therefore several INT sub_tables, these are announced in the same 
IP/MAC notification service structure. 

In that case, the list of announced IP platforms SHALL be complete, so that each INT sub_table within the 
entire DVB network is referred to by at least one linkage_descriptor containing an IP/MAC Notification 
Service Structure. 

A platform_name SHALL be given for each announced IP platform. The platform_name MAY be announced 
just once within each BAT containing IP/MAC Notification Service Structures. 
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To get the names of each available IP platform within a DVB network, a DVB-SH Receiver would read the BAT 
containing linkage_descriptors with linkage_type OxOB. Within such BAT, names of each available IP platform are 
announced. 

4.10 SH frame initialization packet (normative) 

SHIP is defined in [6], annex A. Its usage is refined in this clause. 

4.1 0.1 IVIandatory SHIP parameters 

Mandatory parameters are set according to specified rules except for the following parameters: 

• synchronization_id; 

• individual_addressing_length. 

4.10.1.1 Synchronizationjd 

When SH_delivery_system_descriptor signals a diversity_mode where FEC diversity is used at SH service layer 
(diversity_mode XNOR '1 1 10' = '1111'), the synchronization_id can be set to two different values: 

• SHIP located in common services MUST have their synchronization_id set to 0x01; 

• SHIP located in local services MUST have their synchronization_id set to 0x00. 

Therefore, transmitters located in terrestrial cells (cell_id > 255) MUST behave as usual, synchronizing on SHIP with a 
synchronization_id set to 0x00, and avoid using SHIP with a synchronization_id set to 0x01 that are reserved to 
transmitters located in satellite cell. Transmitters located in satellite cells (cell_id < 256) MUST use the unique SHIP 
with a synchronization_id set to 0x01. 

4.1 0.1 .2 lndividual_addressing_length 

In unicast configuration ('OxOO'<individual_addressing_length<'OxFF') individual_addressing_length informs how many 
tx_identifiers entries there are in the SHIP so that multiple tx_identifiers can be addressed within the same SHIP. Using 
multicast addressing can be more efficient to address a large number of transmitters and therefore makes 
individual_addressing_length useless. Multicast and unicast addressing are therefore exclusive. When multicast 
addressing is used (individual_addressing_length = OxFF), this field can no more be used for setting the number of 
multicast entries. However, the receiver can still derive the number of entries from the section length and the individual 
function_loop_length. It is then still recommended to use several tx_identifier entries per SHIP even in the multicast 
case. 

Using service_synchronization function assumes a multicast tx_identifier addressing scheme is used (length set to 
'OxFF'). 

Using servicejocalization function assumes a unicast tx_identifier addressing scheme is used (length set strictly 
between to '0x00' and 'OxFF'). 

4.1 0.2 Optional SHIP parameters 

In this clause, we precise how some of the optional functions useful in a DVB-SH context SHALL be used: after some 
general requirements, we review cell_id function, servicejocalization function, service_synchronization function, 
TDM_function, LL_service_function and TDM_auxiliary_function. Other optional SH-related (group_membership) or 
non SH-related functions MAY be used in a SH context but do not require specific guidance. 

4.10.2.1 General requirements 

According to clause 4.1.2.1, in the specific case of diversity used at SH service layer (diversity_mode XNOR '1110' = 
'1111'), the SHIP packet SHALL signal the optional parameters in the common service so that any receiver will receive 
this information. 
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If the optional function cannot be transmitted in a unique SHIP because of size, then the information SHALL be split 
into successive SHIP packets because the payload of a SHIP (184 bytes) is not enough for carrying the optional data. 
This happens in the following cases: 

• The list of tx_identifiers cannot be completed within the current SHIP: at least one tx_identifier address has 
been described but more are requested. 

• An optional function cannot be ended within current SHIP: there is not enough bytes left in the current payload 
to complete the function, especially if this function has many iterations: 

For service_localization_function: with a unique multicast address for all cells, we can signal localization 
of 17 cells with 1 service declared in each cell within 1 SHIP. 

For service_synchronization_function: With a unique multicast address and no cell_id, we can signal a 
total number of services of 77. 

To detect the multiple SHIP situation, the terminal cannot use section_length since the latter is limited to 182 bytes, 
therefore preventing this parameter to be used in multiple SHIP context. Wait_for_enable_flag is used for that purpose: 
the terminal discovers that there is a multi-SHIP case because the wait_for_enable_flag is set to '0' on the intermediate 
SHIP and set to '1' on the final SHIP where an enable_function MUST be located. So the terminal has to monitor 
successive SHIP to discover the full configuration. Moreover, in all cases, at each iteration, the individual_addressing 
length signals the length within current SHIP so that total length is the sum of all successive signalled lengths. 

More precisely, the syntax rules are the following: 

• A function MAY be split into several parts called hereunder "the parts". 

• Each part MUST be correctly signalled and compliant with the SHIP specification: 

For a given part, function description MUST be complete: fields function_tag, function_length, data, 
wait_for_enable_flag, reserved MUST be present and correctly set. 

For a given part, function_loop_length MUST be set to the length of the part of the function located 
within current SHIP. 

Wait_for_enable_flag MUST be set to '1' up to the reception of enable_function with the corresponding 
enable_function_tag . 

Function MUST be enabled with reception of the function last part, or the following one if no room is 
available on the last part. 

The complete function CAN be built from individual parts to constitute a compliant function: 

The complete function description MUST be complete: fields function_tag, function_length, data, 
wait_for_enable_flag, reserved MUST be present. 

The complete function_loop_length MUST be set to the sum of lengths of all individual parts and 
MUST be Hmited to 255 bytes. 

Wait_for_enable_flag MUST be set to '1' up to the reception of enable_function with the 
corresponding enable_function_tag. 

Additional following rules are mandated: 

If signalling for a given tx_identifier MUST be split over several SHIP, the same tx_identifier SHOULD be 
used in all successive SHIP (the signalling MUST not change the addressing before completing the current 
one). This applies to both unicast and multicast addressing schemes. 

This rule MAY not be respected with content regionalization cases where different SHIP are generated for the 
global and local regionalized TS. However this rule MUST be respected for the sequence of individual SH 
service present and valid in the same cell. 

The SHIP sequence SHALL be repeated regularly so that any transmitter or receiver performing a cold start 
SHALL be able to retrieve the complete sequence within a small delay and so that a missed intermediate SHIP 
MAY be recovered quickly. 
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4.10.2.2 Txjdentifier 

Tx_identifier syntax depends on individual_addressing_length. See the later for more information. 

4.10.2.3 Celljdjunction 

This cell_id SHALL be present when servicejocalization function is used to give binding information between cell_id 
and SH service (refer to service_localization_function for more information on this binding). 

4.1 0.2.4 Service_localization_f unction 

4.10.2.4.0 Introduction 

This service_localization_function enables to discover what SH services are actually on which region. This function is 
therefore useful for both transmitters and receivers since both need to discover the SH regionalization information. 

The service_localization_function by itself only lists the SH services. In order to provide binding information between 
the region and the SH services, the tx_identifiers and the cell_ids need to be detailed according to the following rules. 

NOTE: This function can be used to signal localization of both LL and RL services. 

4.10.2.4.1 txjdentifier 

For providing binding information between the service_localization_function and the transmitters, the following rules 
on tx_identifier are recommended: 

• For signalling a common SH service alone: an individual tx_identifier (individual_addressing_length strictly 
between 0x00 and OxFF) MUST be used unless the TS is being modulated over several satellite modulators. 

• For signalling a local SH service: a multicast addressing scheme (individual_addressing_scheme equal to 
OxFF) SHOULD be used since in the general case several modulators are located in a terrestrial cell; multicast 
addressing is therefore convenient for informing all the transmitters at once. 

• For signalling a common SH service among other local services: a multicast addressing scheme 
(individual_addressing_scheme equal to OxFF) SHOULD be used in order to address in the same SHIP the 
different transmitters. 

4.10.2.4.2 Celljd 

For providing binding information between the service_localization_function and the receivers, the cell_id function 
MUST be used in the same SHIP as the service_localization_function. Therefore, the receiver can immediately derive 
on which cell_id the signalled SH service is being transmitted. 

EXAMPLE: SHIP detailed in Table 6 gives the regionalization information for a case where we have 2 

common SH service (id = and id = 1) sent on a unique cell (cell_id = 0), and 2 additional local 
SH service sent on 10 local cells (cell_id from 256 to 265). The signalling is done using 1 1 
different multicast groups (1 to 1 1) for the 1 1 different regions (1 for the global region, 10 for the 
local regions). Therefore the individual_addressing_scheme is set to multicast mode. 
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Table 6: Example of SHIP with SHserviceJocalization function 



SH frame_initializationj}acket 


individual iteration bits 


bytes 


value(dec) 


value 


remarks 


transport_packet_header 


32 1 


32 


4 








synchronizationjd 


8 1 


8 


1 








sectionjength 


8 1 


8 


1 


178 


0xB2 


Sze is 1 78 bytes, enabling to determine the number of iterations 


Fbinter 


16 1 


16 


2 






in txjoop when multicast addressing is used 


periodicjiag 


1 1 


1 


0,125 








future_use 


14 1 


14 


1,75 








SH_use 


1 1 


1 


0,125 








synchronization_time_stamp 


24 1 


24 


3 








maximum_delay 


24 1 


24 


3 








tps_stiip 


32 1 


32 


4 








individuaLaddressingJength 


8 1 


8 


1 


255 


OxFF 


multicast addressingis used 


Global txjoop 














txjdentifier 


16 1 


16 


2 


1 


0x0001 


multicast address equals 1 for 1 global region 


functionjoopjength 


8 1 


8 


1 


10 


OxOA 


1 < max value 255 / OxFF bytes 


celljd 


40 1 


40 


5 





0x00 


celljd for 1 global region 


servicejocalizationjunction 


40 1 


40 


5 





0x00 


2 global SH services are signaled 



Local txjoop 

txjdentifier 

functionjoopjength 

celljd 

servicejocalizationjunction 


crc_32 
stuffing. 


_byte 



16 


10 


160 


20 


2 


8 


10 


80 


10 


120 


40 


10 


400 


50 


256 


56 


10 


560 


70 


2 


32 


1 


32 


4 




8 














SHserviceid varies from to 1 



0x0002 multicast address from 2 to 1 1 for the 10 local regions 

0x78 1 20 < max value 255 / OxFF bytes 
0x0100 celljd 256 to 265 for the 10 local regions 
0x02 2 global service(s) and 2 local service(s) are signalled at each iteratic 
Global: 2 ids from to 1 
Local: 2 ids from (2+ k*2) to (3+ k*2) where k is selected in [0;9], 



1504 188 

In this example, there are 1 1 tx_identifier iterations, one for each muhicast group / cell: 

• Multicastjd 1 / celljd 0: 

This group refers to the satellite cell (cell_id 0) where multicast group 1 configures the unique satellite 
transmitter. 

NOTE: Individual addressing is not possible when there are other multicast groups being signalled for local 
repeaters. 

2 SH_services (SH_services and 1) are signalled on this cell, no local SH service is signalled. 

Not only the transmitter is configured but also the receiver, since the receiver can now attach 
SH_services and 1 to cell_id 0. 

• Multicastjd 2 to 1 1 / celljds 256 to 265: 

These groups refer to the 10 local cells (id 256 to 265). 

Different multicast groups are used to signal this information (from address 2 to 1 1). 

Inside every terrestrial cell, the 2 common SH_services (id to 1) are signalled so that every local 
transmitter repeat the 2 common SH_services, in addition to a unique local SH_service selected among 
the 10 possible. 

In the simple case of 1 common SH service and 1 local SH service per region, the maximum number of regions that 
enable to send all signalling in 1 DVB packet of payload size 184 bytes is around 10. If more regions are needed, the 
repeaters can be grouped in different multicast groups, or signalling can be split in successive SHIP packets according 
to rules described in clause 4.10.2.1. 
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4.1 0.2.5 Service_synchronization_function 
4.10.2.5.0 Introduction 

The service_synchronization_function MUST be present in the following cases: 

• Case 1: When diversity is used at SH service layer (diversity_mode XNOR '1110' = '11 11') to signal SH 
services delineation to both transmitters and receivers. 

• Case 2: When class 2 physical interleaver is used to signal SH service delineation to transmitters and receivers 
for power saving and memory reduction (see [7], clause 7.2.3.3.1). 

• Case 3: The service_synchronization_function MAY be present when the number of SH frames per 
superframe is lower than 1 since other means can be used to synchronize transmitters (see [7], 
clause 7.5.1.2.2). 

• Case 4: When LL services are present the multiplex, service_synchronization_function is used to signal 
position of these LL services in the SH frame. 

Depending on each case, the following requirements are put on service_synchronization. 

Table 7: service_synchronization_function requirements 



Constraint/ 
Case 


Number of SH 
services 


Individual SH 
service 


Sum of SH services 


Example 


1 (diversity at SH 
layer) 


At least equal to 
the sum of global 
and local regions 


In each region, one 

SH service IVIUST 

start an SH frame, 

one SH service 

MUST end an SH 

frame 


The SH services have a 

repetitionjnterval which is a 

multiple of SHJrame duration 


See clause 4.2.1.3 


2: long PHY 

interleaver with 

time slicing) 


Inferior or equal to 

the number of 
time-slice services 


Non specific 


The SH services have a repetition 

interval equal to the repetition 

period of the physical interleaver, 

itself being a multiple of SH frames 


See [7], 
clause 7.2.3.3.1 


3: transmitter 
synchronization 


At least 1 


Non specific 


The cumulated length of all SH 

services MUST be higher or equal 

in size to the number of EFRAMES 

per Superframe 


See [6], 
clause A.4.9 


4: LL services 


Superior or equal 
tol 


One LL SH service 

SHOULD start an 

SH frame 


The SH services have a 

repetitionjnterval which is a 

multiple of SH frame duration 


See clause 4.10.2.7 
and [6], annex B 



This service_synchronization_function enables to discover how SH services are actually organized at the level of 
EFRAMES in the TS. This function is therefore useful for both transmitters and receivers since both need to discover 
the SH services distribution. How the service_synchronization_function is signalled depends on the case: 

• In case of content regionalization (case 1 of Table 7), signalling depends on in which regional TS the SHIP is 
located: 

If the synchronization_function is located on the common part, the service_synchronization_function 
MUST be complete and MUST list all SH services present in the complete TS in their sending order. 

If the synchronization_function is located on the local part, the service_synchronization_function MUST 
list only the common and current local service(s) in their sending order, all services being not transmitted 
in this local TS MUST not be listed. 

• In case 2, in addition to the previous rule, the individual time-slices services MUST also be listed in their 
sending order. 

• In case 3, no specific rule is required. 
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• In case 4 when LL services are present, the signalling depends on which part of the content the SHIP is 
located: 

If the synchronization function is located on LL part, the service_synchronization_function MUST limit 
the scope of the description to the SH frame, enumerating services based on their nature (LL or RL). 

If the synchronization function is located on the RL part, then service_synchronization_function must not 
consider the LL services and consider them as RL. 

If the synchronization function is located on the LL part and local content is used, the 
service_synchronization_function SHALL signal the services for the complete SH-Frame, which means 
for the common and the local part. 

If a system configuration with the possibility of code combining is chosen (e.g. SH-B, SAT-TDM, TERR 
- OFDMA), the synchronization function MUST signal the same LL service positions for the common 
part of all modulations. 

For the signalling in case 4 it is necessary to transfer the mux_assoc-vector (given in [6]), which gives the association to 
RL and LL service on codeword basis to a burst-length representation, which is needed for the service synchronization 
function. This can be done by the following steps. 

NOTE: The mux_assoc-vector has a length of New elements, as given in [6], clause B.L4.4. 

• Each consecutive assignment of codeword to one latency mode (either RL or LL) is one burst. Each burst k 
has a starting codeword (named burst_start(k)) and a burst length (named burst_length(k)). 

• Each change in assignment in the mux_assoc-vector defines a new burst start, the following cases are possible: 

1) mux_assoc[i] = (LL), mux_assoc[iH-l] = 1 (RL) defines a burst_start at i-nl; 

2) mux_assoc[i] = 1 (RL), mux_assoc[iH-l] = (LL) defines a burst_start at in-L 

• The first burst gets the index and starts at codeword 0, so burst_start(0) = 0. 

• Given that the change in assignment between i and i-nl is the k-th (k starting at 1) change, the variable 
burst_start(k) = i-nl. 

• The burst_length of burst k is defined by: 

burst_length(k) = burst_start(kH-l) - burst_start(k); 

given that there are n bursts, the last burst length is defined by 
burst_length(n-l) = Ncw-burst_start(n-l). 

• The burst mode (RL or LL) of each burst k is given by mux_assoc[burst_start(k)]. 

The calculated burst lengths are used in the given order from index to n-1 to be inserted in the 
service_synchronization_function in the LL SHIP (case 4) for the "Length" parameter. 

In Figure 17 the co-existence of SH-Services and RL/LL-Services is illustrated: 

• for SHIP located in the LL burst of the SH frame (SHIP in red), the following services MUST be signalled: SH 
(LL) SH 1 (RL), SH 2 (LL), SH 3 (RL); their total length is therefore equal to 1 SH frame; this service 
composition is valid for all SH frames. The organization of services inside the SH frame is called multiplex 
association, in the figure this is related to the sequence of red services SH to SH 3; 

• for SHIP located in RL part of the SH frame (in blue), the picture is different and obliterates the presence of 
the LL burst for signalling the SH-services; therefore, assuming a repetition interval of 3 SH frames for the 
SH-Services, there exist services SH to SH 2, with a total length of 3 SH frames. 
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Figure 17: Scope of service synchronization in LL and RL case 

In Figure 18, the co-existence of Local Content insertion and RL/LL Services is illustrated: 

• For the SHIP in the LL Service, the following services MUST be signalled: SH (LL), SH 1 (RL), SH 2 (LL), 
SH 3 (RL), SH 4 (LL) and SH 5 (RL). The Services sum up to the length of the larger SH-Frame. For the 
shorter SH-Frame, the service signalling for the first codewords up to the length of the (shorter) SH-Frame is 
applied. The boundary of the shorter SH-Frame DOES NOT NEED be the boundary of a signalled service. 

• For the SHIP in the RL Service, the Common (SH 0) and Local Content (SH 1) MUST be signalled. 

• For the SHIP in the RL Service, the ll_service_function SHALL include all available modulation, as the SHIP 
is in the Common Content part and MUST be the same for all transmissions path to keep code combining 
possible (see also clause 4.10.2.7). 

• The RL SHIP in the local content does not bear additional information on the LL Service. There is no local 
content LL SHIP, as each LL Service is generated separately for each modulation. 
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Figure 18: LL Service combined with local content insertion 



4.10.2.5.1 txjdentifier 

Same rules as clause 4.10.2.4.1 apply. 



4.10.2.5.2 



Cell id 



Cell_id is not mandatorily required since the information is TS dependent (if the receiver catches the 
service_synchronization_function, this means it can receive the signalled services, except for the common part for 
which the service_localization_function MUST be used). However for simplification purposes, the same SHIP can also 
provide binding information between the service_synchronization_function and the receivers, the cell_id function 
MUST be used in the same SHIP as the service_localization_function. Therefore, the receiver can immediately derive 
on which cell_id the signalled SH service is being transmitted. 

EXAMPLE: For instance the SHIP detailed in Table 8 gives the service description information on a SHIP 
located on the common part for a case where we have the maximum possible number of SH 
service sent on a unique cell (cell_id = 0). As can be seen, up to 75 services MAY be signalled in a 
unique SHIP. 
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Table 8: Example of SHIP with a service_synchronization_function 



SH frame_initialization_packet individual iteration bits bytes value(dec) value 



remarks 



transport_packet_header 


32 


1 32 


4 




synchronizationjd 


8 


1 8 


1 




section length 


8 


1 8 


1 


178 


Fbinter 


16 


1 16 


2 




periodicjiag 


1 


1 1 


0,125 




future use 


14 


1 14 


1,75 




SH use 


1 


1 1 


0,125 




synchronization Jme_stamp 


24 


1 24 


3 




maximum_delay 


24 


1 24 


3 




tps_ship 


32 


1 32 


4 




individuaLaddressingJength 


8 


1 8 


1 


255 


Global txjoop 










tx identifier 


16 


1 16 


2 


1 


functionjoopjength 


8 


1 8 


1 


160 


cell id 


40 


1 40 


5 





service_synchronization_function 


1240 


1 1240 


155 





crc 32 


32 


1 32 


4 




stuffingbyte 


8 











0xB2 



Sze is 1 78 bytes, enabling to determine the number of iterations 
in txjoop when multicast addressing is used 



OxFF multicast addressingis used 



0x0001 multicast address equals 1 fori global region 

OxAO 1 60 < max value 255 / OxFF bytes 

0x00 celljd for 1 global region 

0x00 75 global SH services are signaled 



1504 188 



4.10.2.6 



TDM function 



4.10.2.6.1 



Presence of the TDM function 



TDM function presence in the SHIP depends on the SH_delivery_system descriptor modulationjoop according to 
Table 9. The table lists all cases where TDM function has to be present. For all other cases TDM function shall not be 
present. 

Bit field diversity_mode provides further details on the configuration of TDM and OFDMA modulations for the given 
TS, but this has no impact on the required presence of TDM_function. 

Table 9: Mapping SHdeliverysystemdescriptor on SHIP TDMfunction 



Modulation loop 


Case 


TDIVI function distribution 


Presence of 1 unique 
modulation_type set to '0' 


Only 1 TDM modulation used 


TDM_function is present 

tx identifier usage not needed 


Presence of several 
modulation_type set to '0' 


Several TDI\/I modulation used 


TDM_function is present 
txjdentifier usage is needed 



4.10.2.6.2 Txjdentifiers and sending rules for TDM function 

The following rules on tx_identifier are recommended: 

• If the TS is broadcast on one satellite beam only, the broadcast addressing scheme SHOULD be used 
(individual_addressing_length strictly between 0x00 and OxFF and tx_identifier equal to 0x0000). 

• If the TS is broadcast on several satellite beams, the individual addressing scheme 
(individual_addressing_length strictly between 0x00 and OxFF) SHOULD be used for addressing the TDM 
transmitters, and: 

In case of an SH-B network with no paTS, a multicast addressing scheme 
(individual_addressing_scheme equal to OxFF) SHOULD be used for addressing the OFDMA 
transmitters since in the general case several modulators are located in a terrestrial cell; multicast 
addressing is therefore convenient for informing all the transmitters at once. 

In case of an SH-B network with paTS, the broadcast addressing scheme SHOULD be used 
(individual_addressing_length strictly between 0x00 and OxFF and tx_identifier equal to 0x0000) if 
possible for addressing the OFDMA transmitters; otherwise a multicast addressing scheme 
(individual_addressing_scheme equal to OxFF) SHOULD be used. 
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NOTE 1 : One example is the cases where a TS is being modulated over several beams, each one having different 

TDM parameters with different capacity on each beam carrying same common content but different 'local 
content', or same capacity carrying same common content with different modcod (for instance T- 
QPSKl/2 has same capacity as T-8PSK1/3). 

NOTE 2: The case where a beam has a different type of modulation in the modulation loop is excluded. It is not 
recommended to have a mix of OFDMA and TDM modulations that represents a non-canonical 
configuration (neither SH-A nor SH-B). Therefore it is not possible to have SHIP without TDM functions 
included, even with a tx_identifier usage to scope satellite OFDMA transmitters on one case, satellite 
TDM transmitters on the other case. 

NOTE 3: When there is a paTS, the TDM function is present in the global SHIP and the local SHIP, if any. 

The following rules on the TDM function transmission are recommended: 

• When the broadcast or individual addressing scheme is used for signalling a TDM function, this TDM function 
must be sent as often as possible, and at least once every 10 seconds period. 

• When the multicast addressing scheme is used for signalling a TDM function, this TDM function must be sent 
at least once every 10 seconds period. 

EXAMPLE: Case of an SH-B network with paTS and in which the Global TS is broadcast on 2 satellite beams. 

We assume that there is one terrestrial SEN area under the first satellite beam coverage, and one terrestrial SEN area 
under the second satellite beam coverage, each of these areas having its own local content, and its own specific SHIP 
(with synchronization_id = 0x00). 

The SHIP with synchronization_id = 0x01 may be used to configure the TDM transmitter of each beam. In that case, 
the two TDM functions should be unicast in each SHIP, except SHIP using the multicast addressing scheme (for the 
transmission of other purpose functions). 

The SHIP of the Local TS (SHIP with synchronization_id = 0x00) broadcast on the first terrestrial SEN area may be 
used to configure the OEDMA transmitters of this area: in that case, one unique TDM function should be broadcast in 
each SHIP, except SHIP using the multicast addressing scheme (for the transmission of other purpose functions). The 
same rule applies to the Local TS broadcast on the second terrestrial SEN area. 

The TDM function shall be interpreted by transmitters according to tx_identifier usage: 

• if tx_identifier matches the transmitter actual identifier (broadcast mode '0x000', transmitter belongs to the 
multicast group designed by tx_identifier, transmitter identifier is equal to unicast tx_identifier) then the 
corresponding transmitter must interprete the TDM function; 

• if tx_identifier does not match actual transmitter identifier, then this TDM function must simply be ignored by 
the transmitter. This does not preclude the possibility to process another TDM function with a different 
tx_identifier; 

• by monitoring reception of ship packet having target tx_identifier and tdm_function at least every 10s, the 
transmitter derives presence of tdm function and SH-B configuration. 

4.10.2.6.3 TDM bandwidth 

The TDM bandwidth is transmitted inside the TDM function as specified in [6], Table A.21. Depending on the relative 
values of the TDM and OEDMA bandwidth, the equal or unequal conditions can be derived immediately. Depending on 
the case, the TDM modulator derives the symbol rate according to the rules expressed in [6], clause A.4.10 note. 

4.10.2.7 LL_service function 
4.10.2.7.1 Use of the ll_service_function 

The LL service function enables the modulator to encode the LL service with the correct code rate and puncturing 
pattern and it enables the receiver to decode the LL service. If the LL service function is placed in the SHIP, an LL 
service is present in the current stream. There SHALL not be more than one LL service function in a SHIP. 
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The LL_service_function signals the parameters for the LL services separately for each modulation (modulation loop). 
Each signalled LL service gets its own modulation loop iteration. The modulation type is indicated by the 
modulationjd with the possible values SAT, TERR HP and TERR LP: 

• The LL_service_function SHALL at least contain a modulation loop for the modulation it is transmitted. 

• The LL_service_function MAY have loops for modulations related current modulation: 

a SHIP over the satellite MAY include a modulation loop for the CGC (and vice versa) 
an OFDMA HP MAY signal an OFDMA LP (and vice versa) 

in case of an SEN over SAT and TERR, both modulations MUST be included to keep the SEN working 
In case of OEDMA hierarchical modulation, the following applies: 

• Each of the two TS bears its own SHIP and own LL_service_function and possibly different puncturing 
patterns. 

• In case of OEDMA hierarchical modulation, when the two TS are regarded as independent, the signalling of 
the other stream is not necessary, meaning the LL_service_function in the OEDMA HP stream MUST not 
signal the LL parameters of the LP stream (and vice versa). 

• In all other OEDMA hierarchical modulation cases, the LL_service_function in the OEDMA HP stream MAY 
signal the LL parameters of the OEDMA LP modulation (and vice versa). 

NOTE 1 : If there is more than one transmission path and code combining between them is intended, the LL 

services on the common part uses the same positions (refer to clause 4.10.2.5) on all streams. However, 
the puncturing pattern, time interleaver, LL service latency and the content of the LL service MAY be 
different on each path (nevertheless the regular services are the same and code combinable on the 
common part). 

NOTE 2: Code combining is not to be used for LL services for the sake for low latency. 

4.10.2.7.2 Possible locations of the ll_service_function 

The signalled parameters are valid for the modulation of the current loop iteration. The ll_service_function can be 
placed in the SHIP of the LL and the RL service: 

• RL SHIP: 

Eor OEDMA, the placement of the function in the RL SHIP is mandatory. 

Eor TDM, the placement of the function in the RL SHIP is optional since the necessary parameters are 
available via the Signalling Eield. 

• LL SHIP: 

The placement of the function SHOULD be made in the LL SHIP. 

The placement of the LL SHIP at the start of the SH-Erame in the first codeword of an LL burst is 
RECOMMENDED to be able to use fast access strategies (see clause 4.10.2.7.4), in particular for 
OEDMA: 

■ In OEDMA, the ll_ship_cw parameter set to a value not being zero ensures access to the LL service 
but does not ensure fast access as the RL SHIP is available after the RL interleaver delay. 

■ When ll_ship_cw parameter is set to zero, a receiver which knows the LL puncturing pattern by the 
SH_delivery_system descriptor can directly decode this codeword and acquire the LL SHIP and so 
have access to the complete LL service without decoding the RL service in advance. 
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4.10.2.7.3 Signalled Parameters 

The following parameters are signalled: 

• Puncturing pattern: the ll_service_function bears the puncturing pattern of the LL service, which may be 
different from the RL puncturing pattern. 

• Start code word: 

If ll_ship_cw_present is present, it signals the start codeword of an LL service burst. 

If this parameter is not present, then the SH-Frame SHOULD start with an LL service burst (see 

clause 4.10.2.7.2) and the first LL codeword (EFRAME) of this LL service burst SHOULD carry the LL 

SHIP. 

• Service index: the first_service_index in the LL_service_function defines whether the first signalled service is 
assigned to RL or LL. The successive services alternate strictly between these two possibilities. 

NOTE 1: First_service_index has to be set to mux_assoc[0]. 

NOTE 2: The service positions (LL and RL) are signalled by the service_synchronization_function in the LL SHIP. 

4.10.2.7.4 Accessing the LL stream 

• TDM case: The LL service can be discovered directly since by evaluation of the Signalling Field all necessary 
parameters (as the puncturing pattern, and service structure) are available. The LL service can then be 
decoded. 

• OFDMA case: the service discovery splits into a two-step algorithm: 

The SHIP of the RL service has to be acquired, which gives the LL code rate and the position of the LL 
SHIP. 

After acquiring the LL SHIP, the multiplex association-vector (via service_synchronization_function and 
first_service_latency_mode in ll_service_function) is known and the full LL service is available. In 
Figure 19 this approach is given as flow-diagram. 

NOTE: As explained in clause 4.10.2.7.2, placing the LL SHIP at the beginning of the SH frame enables fast 
acquisition of the LL SHIP without the need to acquire the RL SHIP. 
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4.10.2.7.5 



Figure 19: Flow-Chart on how to get access to the LL services 



Example 



The example in Figure 20 illustrates the mapping of the service assignment to the SHIP and the Signalling Field in 
TDM: 

• The Signalling Field bears the length of all used services in their order. The association to the latency_mode 
(RL/LL) is done via a bit for each service separately. 

• In the SHIP two different functions are used. The service_synchronization_function (in the LL SHIP) is used 
to signal the services structure. The association of the services is done by the first_service_latency_mode for 
the first service and each modulation separately in the RL SHIP. The following services are associated to RL 
and LL strictly alternating. 
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Figure 20: RL/LL Service Structure in Signalling Field (SF) and SHIP (e.g. first service is LL) 

4.10.2.7.6 Re-multiplexing 

The processing steps for re-multiplexing have to be separated for the different modules involved. These modules are; 

• Encapsulator 

• Modulator 

• Demodulator 

• De-Encapsulator 

The processing of the Modulator is defined and described in detail in [6]. The processing steps for the Encapsulator is 
described here below. The processing of demodulator and de-encapsulator (receive side) are according to the transmit 
side. 

The re-multiplexing is signalled by the wait_for_enable_flag. The new configuration becomes valid in the SH-Frame 
after the configuration is enabled. 
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Switching the assignment of a codeword from RL to LL or vice versa on the SH-Frame boundary would lead to a loss 
of data as the influence of the time interleaver is not obeyed. In case of re-multiplexing the low latency adaptation of the 
MPEG TS stream (with known SH-Frame boundaries) SHOULD be done in a way that no payload will be lost. Two 
use-cases need to be considered: 

■ Case 1: Switching a codeword assignment from LL to RL 

As the LL interleaver is a short interleaver not longer than an SH-Frame, a guard time of one SH-Frame is 
required for switching the codeword (see example 1). 

■ Case 2: Switching a codeword assignment from RL to LL 

For the switching from RL to LL, the RL interleaver must be considered. The guard time (in SH frames) before 
using the codeword position for LL is calculated from the length of the longest tap rounded up to the next 
integer number of SH-Frames (see example 2). 

NOTE 1 : In an SH-B system with interleaver delay compensation, the interleaver with the longer interleaver delay 
has to be used for the guard time calculation. It has to be used for both transmission paths). 

NOTE 2: Not obeying these rules (inserting guard time) for re-multiplexing does not cause catastrophic situations, 
but to a loss of some payload data (either on RL or LL, or both) due to non-decodable codewords at the 
receiver. This situation has a (maximum) length in the order the guard time of the RL interleaver (see 
above. Case 2). Then all RL and LL codewords can be decoded error free again. 

The RL Service, which is modulated, must form a LL adapted TS, which means, that it consists of the RL Service 
payload and inserted NULL TS packets, which form the RL gaps. The LL Service does not need to be adapted. It 
consists of the LL Service payload at the correct data rate to fill the LL bursts related to the RL gaps. 

EXAMPLE 1 : (Switching a codeword assignment from LL to RL) 

• in SH frame # -1 the switching of a codeword is decided (a new configuration may be 
transmitted in advance with the wait_for_enable_flag set); 

• in SH frame # 0: 

in LL stream: all MPEG-TS packets related to the switched codeword are filled with 
Null MPEG TS packets 

in RL stream: the switched codeword is still unused, i.e. filled with Null MPEG TS 
packets 

the LL-SHIP of this SH-frame carries the new configuration, i.e. the new configuration 
is now enabled (by enable_function) 

• in SH frame #1 (and further): 

in LL stream: only codewords related to the new configurations are available (payload 
only) (reduced by 8 MPEG-TS packets for the switched codeword) 

in RL stream: the switched codewords are now used for RL payload MPEG-TS. 

EXAMPLE 2: (Switching a codeword assignment from RL to LL, assuming an RL interleaver length of L 
frames) 

• in SH frame # -1 the switching of a codeword is decided (a new configuration may be 

transmitted in advance with the wait_for_enable_flag set); 

• in SH frame # up to frame # L- 1 : 

in LL stream: only payload MPEG TS packets related to the configuration before re- 
multiplexing (a new configuration may be transmitted in advance with the 
wait_for_enable_flag set); 

in RL stream: all MPEG-TS packets related to the switched codeword are filled with 
Null MPEG TS packets, i.e. the RL payload is immediately reduced. 
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in SH frame # L: 



in LL stream: only payload MPEG TS packets related to the configuration before re- 
multiplexing (same as the frames before); 

in RL stream: all MPEG-TS packets related to this codeword are filled with Null MPEG 
TS packets (same as the frames before); 

the LL-SHIP of this SH-frame carries the new configuration, i.e. the new configuration 
is now enable (by enable_function). 

• in SH frame # L+1 (and further): 

in LL stream: the number of codewords related to the new configuration are now 
available (all filled with payload) (increase by 8 MPEG-TS packets for the switched 
codeword); 

in RL stream: all MPEG-TS packets related to this codeword are filled with Null MPEG 
TS packets (same as the frames before). 

4.1 0.2.8 TDM_auxiliary function 

The tdm_auxiliary_function signals the TDM PL scrambling sequence to the modulator as specified in [6], Table A.24. 
According to [1], clause 6.4.4.1 the value of scrambling parameter n (as defined by [1], clause 5.6.4.3) is signalled via 
field scrambling_lsbs inside tdm_auxiliary_function. 

If scrambling_mode in SH delivery_system_descriptor = 1, then scramblingjsbs is the result of 
uint(polarization) * 2'^6 + uint(cell_ID(b5 : bO)), otherwise scrambling_lsbs = 0. This relation is summarized in 
Table 10. 

Table 10: scramblingjsbs 



scrambling_mode 


scrambling Isbs 


number of bits 





uimsbf (0) 


8 


1 


uimsbf{ uint(polarization) * 2'^6 + uint(cell id(5:0)) } 


8 



4.11 Signalling field 

Signalling field is defined in [6], clause 5.5.5.2. Its usage is refined in this clause. 

The signalling field MUST be used to signal the cell_id via the field transport_stream_identifier. The 8-bit field enables 
to signal a value between and 255 which are the allowable values for satellite cell_id. 

If Low Latency Services are used, they SHALL be announced in the signalling field. The parameter "nof_bursts" is set 
to the value n-1, where n gives the number of bursts (RL and LL) in one SH-Frame (see clause 4.10.2.5.0). The 
parameter "burstjength" is set to burst_length(k), where k gives the number of the loop iteration in the signalling field, 
where the first loop has the index 0. The parameter "latency_mode" is set to mux_assoc[burst_start(k)]. 
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